Open Grid
PHPcon 2011 Link Dump
Mąchocice k. Kielc goszczą tegoroczną konferencję PHPcon2011. Jest to wspaniała okazja do wymiany doświadczeń z innymi programistami face2face oraz możliwości posłuchania z jakimi problemami borykają się największe serwisy w Polsce (Allegro, NK). Stu osiemdziesięciu programistów w tym prelegenci tacy jak Lorna 'LornaJane' Mitchell, czy Derick Rethans.
Warto było przyjechać, mimo że pewnej grupie prezenterów należą się baty za brak należytego przygotowania swojego "show". Jeszcze nie koniec (#PHPconpl), ale zebrałem tymczasem kilka przydatnych linków wartych odwiedzenia...
Dodatki usprawniające pracę programisty
- ClipX uzupełnia klasyczny schowek Windows optymalizując technikę programowania opracowaną przez Copyiego N. Pasta
- Enso Launcher to nakładka pozwalająca na szybkie odpalanie poleceń systemowych z klawiatury
- Guake szybki dostęp do konsoli ala Quake
Monitoring serwerów i aplikacji
Optymalizacja
- XDebug w połączeniu z graficznymi interfejsami jedno z najlepszych narzędzi do optymalizacji kodu PHP
Repozytorium kodu
- Megiforge w odróżnieniu do Github'a pozwala na darmowe hostowanie prywatnych repozytoriów i nie tylko Git
Frameworki godne uwagi
Grafowe bazy danych
- OrientDB wypełnia lukę w implementacji grafowych baz danych, który świetnie trafiają w potrzeby współczesnych aplikacji webowych. Slajdy na temat OrientDB
Wyszukiwanie
- Solr został wdrożony przez Allegro zastępując dotychczasową implementację wewnętrzną
Deployment SQL
Comments to "PHPcon 2011 Link Dump":
2 | OpenGrid
@pecet jednak hastag jest #phpconpl, co do samego Twittera to jednak polska społeczność frontendowa mocno się na nim trzyma.
4 | pecet
nie żyje tak samo jak jogger, a i tak ma wielką społeczność (ps. większą niż umarły jogger)
5 | n
na blipie tag #phpconpl jest pusty (jeden feed z twittera), a na twitterze cos sie dzieje wiec jakby sytuacja jest jasna.
6 | Piotrek Reinmar Koszuliński
Wciągnęło mi komentarz, który pisałem przez 30 minut. Zamorduję kogoś jeśli Jogger go odrzucił, nie zwracając mi go w żaden sposób...
7 | pecet
Reinmar -- masz za swoje, polecam rozszerzenie Lazarus dla przeglądarki Mozilla Firefox, bez tego ani rusz :)
8 | Piotrek Reinmar Koszuliński
To piszę jeszcze raz k** :D Pierwszy raz od dawna nie zrobiłem ctrl+c przed wysłaniem komcia i taka kara mnie spotyka :(
Tak się składa, że korzystam od niedawna z bazy OrientDB (łączonej z PHP) w swojej pracy inżynierskiej. Z początku byłem bardzo pozytywnie nastawiony, bo nasza aplikacja będzie wizualizowała sieć AS (systemów autonomicznych - w skrócie: dużych grafów :). Po miesiącu prac, kilku błędnych decyzjach i wielu zmarnowanych godzinach wyrobiłem sobie już pewne zdanie na ten temat i może ono kogoś zainteresuje.
1) Driver binarny, który został wspomniany w prezentacji ma tragicznie napisany parser. Wygląda jak przeportowany z C (przeważnie metoda: znak po znaku). Parsowanie dużego grafu zajmuje mu 40x więcej czasu niż metoda z REST-owym API i JSON-wym formatem (czyli json_decode). Gdybym rypał bazę wieloma zapytaniami, to może byłby jakiś zysk z binarnego drivera, ale tak, to nadaje się do śmieci.
2) Drugi driver (congowa) jest przyjemny, ale słabo przetestowany. W ciągu tygodnia znalazłem dwa poważne błędy. Jeden, mimo mojego pull requesta na githubie, nie został wciąż poprawiony.
3) Driver congowa nie ma poza krótkim wstępem żadnej dokumentacji. Kod na szczęście czyta się znośnie i ma sporo testów (choć te mi nic nie dały).
4) Sam OrientDB jest niezbyt stabilny. Rzucał mi na konsoli wyjątkami i kilka razy się scrashował, a nie pracowałem na jakichś wielkich strukturach danych.
5) Zapytania SQL są bardzo podatne na to jak się je zada. Np. "UPDATE ASNode SET x=x WHERE @rid=#1:1" jest kilka rzędów wielkości wolniejsze od "UPDATE #1:1 SET x=x". Tak więc brakuje prostych optymalizacji i (co zostało już po moim pytaniu na grupie dysk. poprawione) brakowała dokumentacji na ten temat.
6) Parser do SQL-a jest toporny. Wymaga spacji w jakichś dziwnych miejscach. Np. wewnątrz nawiasów (slajd bodajże 137.)
7) Jest plus! Pobranie struktury grafu od danego wierzchołka do np. 10 poziomów wgłąb (kilka tysiecy wierzchołków i tyleż samo krawędzi) trwa ułamek sekundy. Myślę, że wynik nieosiągalny z MySQL-em.
8) Jest i minus. Fetch plany wykorzystywane do tego typu zapytań zachowują się mocno niezrozumiale. Zadaliśmy ("my", bo praca inż. na IZ@PWR jest grupowa ;<<<) o to pytanie na grupie dysk. i dowiedzieliśmy się, że możliwe, że jest błąd. Korzystamy z 1.0rc6 i wydaje mi się, że to jeden z ważniejszych ficzerów...
9) Zapytania typowo SQL-owe są dramatycznie wolne. Dla 36k rekordów i indeksu typu unique na polu "num", czas wykonywania zapytania "SELECT FROM ASNode WHERE numasstring LIKE '1234%'" to 1.19s, następnie 0.3s. Po zmianie stringa - 0.5s. Mam peceta z i5 7XX.
10) traverse(), który jest ważnym operatorem, jest bardzo słabo opisany i nie udało mi się znaleźć żadnych poważniejszych przykładów zastosowań. W dodatku dla naszej bazy 36k wierzchołków i 110k krawędzi czasy trwania zapytań są takie, że jak wracam z kuchni tostami, to muszę okno otworzyć, bo procek mi podnosi temperaturę w pokoju, a wyników jak nie było, tak nie ma.
Generalnie - podoba mi się idea baz grafowych. W ogóle noSQL w każdej postaci jest mi bliski. Niestety Javowy OrientDB mnie nie powalił - w wielu miejscach jest po prostu zaskakująco powolny. Jest tak powolny, że czasami boję się wykonać zapytanie na konsoli :D... Możliwe, że lepiej współpracuje z Javą niż z PHP-em, ale wielkich różnic bym się nie spodziewał. Choć... tyle dziwnych rzeczy już się wydarzyło w związku z Orientem, że to może opinia na wyrost.
BTW. kto pisze bazę danych w Javie?!
1 | pecet
23 october 2011, 09:57:49
Protip Twitter jest dla anglojęzycznych wpisów, a PHPcon się odbywa w Polsce. Od polskich wpisów jest umierający Blip.