Wojny z materią

Poddani Mediaamby?

admin — Fri, 20 Nov 2009 08:17:10 +0000

Po zakończeniu projektu znalazłem na swoim biurku elegancko zapakowaną w antyramę laurkę następującej treści:

Tak to jest, jak się dyrekcja dorwie do literatury.

Podzapytania w INSERT

admin — Thu, 03 Sep 2009 09:14:08 +0000

Taki typowy problem: tabela zawierająca pole, pozwalające użytkownikowi na dowolne ustalanie kolejności rekordów. Prawie każda aplikacja ma coś tego typu. W jednej z moich aplikacji była to płaska lista kategorii:

CREATE TABLE kategorie (
id INT NOT NULL AUTO_INCREMENT,
nazwa VARCHAR(255),
position INT,
PRIMARY KEY(id));

Dodanie rekordu do tej tablicy ma domyślnie umieścić go na końcu listy. Często spotykanym (i bardzo kiepskim) rozwiązaniem jest użycie dwóch zapytań: SELECT, który odczytuje aktualną wartość pola position oraz INSERT, który dodaje nowy rekord. A czy da się to zrobić jednym zapytaniem? Pierwszy pomysł jest następujący:

INSERT INTO kategorie(nazwa, position) VALUES (
:nazwa, (SELECT IFNULL(MAX(position) + 1, 1) FROM kategorie)
)

Fajny pomysł, prawda? Ma tylko tą drobną wadę, że nie działa.. próba jego uruchomienia skończy się komunikatem:

#1093 - You can't specify target table 'kategorie' for update in FROM clause

Jak to obejść? Najlepiej podzapytaniem:

INSERT INTO kategorie(nazwa, position) VALUES (
:nazwa, (
SELECT IFNULL(x, 1) FROM (SELECT MAX(position)+1 AS x FROM kategorie) AS subQuery
))

Ładnie, prawda? Opakowanie podzapytania w następne podzapytanie rozwiązuje zadanie. Niestety - tylko dla MySQL w wersji 5.0+. Użycie go na serwerze 4.1 kończy się tym samym komunikatem, co poprzednie… Szczerze mówiąc - nie chciało mi się kombinować. Spłodziłem coś takiego:

INSERT INTO kategorie(nazwa, position) VALUES (:nazwa, 0);
UPDATE kategorie
INNER JOIN (SELECT MAX(position)+1 AS x FROM kategorie) AS subQuery
SET position = x
WHERE position = 0;

Proste? Proste.

Obsługa drzew w SQL - część 2 - Model ścieżki zmaterializowanej

admin — Wed, 15 Jul 2009 09:51:36 +0000

W poprzednim wpisie pokazałem typowe podejście do zagadnienia drzew w SQL (notabene: nazywa się on modelem sąsiedztwa), omówiłem też jego podstawowe wady (i zalety) i obiecałem opisać inne podejście - pozbawione wad modelu sąsiedztwa.

Jeśli przyjrzysz się przykładowemu drzewu, który chcemy zapisać w bazie danych, można zauważyć, że położenie w drzewie można także opisać jako listę wszystkich węzłów nadrzęnych danego węzła. Taka lista nosi nazwę “ścieżki”, i zapisuje się ją licząc od najstarszego rodzica aż po bieżący węzeł. Przykładowo, ścieżka dla węzła “4″ ma postać: “1,2,4″, a dla węzła “11″ - “1,3,10,11″. Dodatkowo, przyda się kolumna informująca, na jakim poziomie znajduje się dany węzeł względem początku drzewa (teoretycznie można tą informację wyciągnąć z długości ścieżki - ale takie zadanie jest, niestety, nierelacyjne, a co za tym idzie - bardzo obciążające dla bazy)

W bazie danych może to wyglądać tak:

table tree_mpath:
id	mpath	level	data
1	1	0	...
2	1,2	1	...
3	1,3	1	...
4	1,2,4	2	...
5	1,2,4,5	3	...
6	1,2,4,6	3	...
7	1,2,7	2	...
itd.

Co daje taki zapis? Przede wszystkim, pozwala z łatwością, pojedynczym zapytaniem, pobieramy fragmenty drzewa:

SELECT id, mpath, level, DATA FROM tree_mpath
WHERE FIND_IN_SET(id, (SELECT mpath FROM tree_mpath WHERE id = 4))
ORDER BY level;

zwróci:

id	mpath	level	data
1	1	0	...
2	1,2	1	...
4	1,2,4	2	...

czyli wszystkie elementy nadrzędne węzła 4 (wraz z tym węzłem, co akurat łatwo wyfiltrować).

Do pobierania elementów podrzędnych węzła możemy użyć zapytania:

SELECT id, mpath, level, DATA FROM tree_mpath
WHERE mpath LIKE (SELECT CONCAT(mpath, '%') FROM tree_mpath WHERE id = 4)
ORDER BY level

które w wyniku da nam:

id	mpath	level	data
4	1,2,4	2	...
5	1,2,4,5	3	...
6	1,2,4,6	3	...

Pobieranie fragmentu drzewa też nie jest trudne: powiedzmy, że chcemy pobrać tylko bezpośrednich potomków węzła o id = 2:

SELECT id, mpath, level, DATA FROM tree_mpath
WHERE mpath LIKE (SELECT CONCAT(mpath, '%') FROM tree_mpath WHERE id = 2)
AND level = (SELECT level+1 FROM tree_mpath WHERE id = 2)

i w efekcie dostaniemy:

id	mpath	level	data
4	1,2,4	2	...
7	1,2,7	2	...

Jak widać - zalety tego modelu są znaczne. Praktycznie dowolny fragment drzewa można czytać pojedynczym zapytaniem, zarówno “w górę” jak i “w dół” od wskazanego węzła. Oczywiście, dla sprawnego działania na taką tabelę należy nałożyć odpowiednie indeksy: na pole id (to chyba oczywiste), mpath oraz level.

Jakie są wady tego modelu?

1. Wysoki koszt aktualizacji. O ile dodanie nowego rekordu jest całkiem znośne, usunięcie również jest całkiem szybkie (choć wymaga dość złożonych warunków, podobnych do tych używanych w zapytaniach SELECT), to przesuwanie węzła w inne miejsce w drzewie jest drogą przez mękę: nie dość, że trzeba zaktualizować przesuwany rekord, to należy też zmodyfikować wszystkie jego węzły potomne. Biorąc pod uwagę, że aktualizacji podlegają indeksy, narzut czasowy jest poważny.

2. Spójność danych. Konstrukcja tabeli nie pozwala na używanie kaskad przy usuwaniu rekordu. W efekcie błąd może doprowadzić do powstania węzłów-zombie, nie powiązanych z pozostałą strukturą drzewa.

3. Ograniczenia wielkości. Jeśli pole mpath będzie polem typu VARCHAR, trzeba pamiętać, że maksymalna długość tego pola to 255 bajtów. Jeżeli identyfikatory kategorii będą 3-znakowe (100-999), to każdy poziom zagłębienia będzie zabierał 4 bajty (identyfikator + przecinek), co daje maksymalny poziom zagłębienia ok. 60. Przy identyfikatorach 4 znakowych (1000-9999), maksymalny poziom zagłębienia to ok. 50. Przy dłuższych identyfikatorach (np. 36-bajtowy uu_id z MS SQL Server) maksymalna wielkość drzewa drastycznie spada (6 poziomów dla uu_id).

Zmiana typu mpath na TEXT rozwiązuje ten problem, ale może się pojawić problem z indeksowaniem takiego pola - np. MySQL nie pozwala na zakładanie indeksów na pole TEXT w InnoDB.

4. Normalizacja. Konstrukcja pola mpath łamie postać normalną tabeli. Zawartość pola level jest wprost powiązany z zawartością pola mpath (level ma wartość “długość ścieżki - 1″), i teoretycznie mógłaby zostać pominięta.

Istnieje rozwiązanie problemów 2-4 - nazywa się znormalizowanym modelem ścieżki zmaterializowanej. Ale o tym innym razem…

Zmiany, zmiany, zmiany…

admin — Fri, 05 Jun 2009 07:28:18 +0000

Nie było okazji wspomnieć:

pracuję tam, gdzie pracowałem
ale - z różnych przyczyn (kryzys w US!) już nie mam większego kontaktu z ColdFusion
teraz moim podstawowym językiem jest PHP
a MySQL zastąpił SQL Server
za to zakres produkowanych serwisów drastycznie się rozszerzył: oprócz aplikacji ecommerce tworzę również CMS-y i serwisy społecznościowe
dzięki temu notki mają szansę traktować o czymś więcej niż sklepy internetowe.

I tyle.

Obsługa drzew w SQL - część 1

admin — Thu, 04 Jun 2009 14:43:54 +0000

Praktycznie w każdym projekcie informatycznym (a w e-commerce w szczególności) pojawiają sie jakieś struktury drzewiaste. Ich zapisywanie do bazy danych stanowi problem, ponieważ tabele baz danych są przystosowane do zapisu ‘liniowego’ a nie drzewiastego.

Załóżmy, że mam taką strukturę drzewa (cyferki oznaczają identyfikatory węzłów):

Najczęściej używaną strukturą jest wstawianie do rekordu potomnego klucza obcego wskazującego na rekord-rodzic bieżącego rekordu. Tabela tree będzie zawierała następujące dane:

id	parent_id		data
1 	NULL 		…
2 	1 		…
3 	1 		…
4 	2		…
5 	4 		…
6 	4 		…
7 	2 		…
itd

Sens tych wartości jest oczywisty: każdy rekord zawiera referencję na rekord ‘nadrzędny’ (rodzica). Rekord od id = 1 nie ma rodzica - w związku z tym parent_id = NULL.

Co daje taki model? Na pewno bardzo proste wstawianie nowych rekordów. Równie proste jest przesuwanie - jednym zapytaniem można przesunąć całą gałąź do innego węzła. Z usuwaniem sprawa nie jest już taka prosta, ale można skorzystać z kaskady (ON DELETE CASCADE), która bardzo ładnie usunie całą gałąź poniżej usuwanego elementu.

Problem w tym, że wstawianie, usuwanie i przesuwanie to nie są operacje najczęściej wykonywane na drzewie. Typowe operacje to: “pobierz wszystkie węzły potomne oddalone o mniej niż 2 od wskazanego węzła“, albo “pobierz wszystkie węzły macierzyste wskazanego węzła“. W praktycznych zastosowaniach pierwsza operacja odpowiada np. budowaniu nawigacji na podstawie drzewa kategorii, druga zaś - tworzenia ścieżki dostępu (tzw. breadcrumbs) od bieżącej kategorii do strony głównej serwisu.

SQL nie zawiera wydajnych narzędzi czytania drzew zdefiniowanych tak, jak w powyższym przykładzie. W efekcie każda próba odczytania dowolnego fragmentu drzewa wymaga wielokrotnych zapytań do bazy danych - po jednym dla każdego poziomu przy czytaniu “w górę”, i co najmniej po jednym na każdy poziom przy czytaniu w dół. Przy serwisach z bardziej złożonym układem kategorii narzut związany z budowaniem nawigacji może być bardzo znaczący. Oczywiście, można użyć jednej z wielu technik cachowania, ale cache tylko maskuje prawdziwy problem.

Na szczęscie jest metoda pozwalająca na odczytanie dowolnego fragmentu drzewa pojedynczym zapytaniem - kosztem bardziej złożonej procedury dodawania i modyfikacji drzewa. Ale o tym w następnym wpisie.

Zagapiłem się…

admin — Thu, 04 Jun 2009 13:23:40 +0000

Zagapiłem się, i przez wiele miesięcy (ponad rok!) nie zaglądałem na bloga… aż tu nagle - wirus, trojan, exploit i inne paskudztwa.

Trochę posprzątałem, coś tam naprawiłem i mam nadzieję, że google usunie mnie z indeksu stron niebezpiecznych. Kazali “sprawdzić za jakiś czas”…

Dropshipping - powiedz nienieniearghhhh

admin — Thu, 15 May 2008 10:43:16 +0000

Przeczytałem sobie taką notkę o dropshippingu. Idea nawet fajna, ale pomija istotną sprawę: firma zarabia na wartości dodanej. Czym więcej kluczowych funkcji biznesowych będzie realizowanych poza firmą, tym mniejszą wartość dodaną generuje. A zamawianie towaru w hurtowni, pakowanie i wysyłanie do klienta jest chyba jedną z kluczowych funkcji sklepu internetowego, czyż nie?

Prędzej czy później dojdzie do nieuniknionego: dostawca uruchomi własny system zamówień, poinformuje wszystkich klientw sklepu, zaoferuje niższą cenę i żegnaj biznesie złoty…

Dropdowny, Ajax i usability

admin — Thu, 15 May 2008 10:28:15 +0000

Generalną zasadą budowy dostępnego interfejsu jest takie jego przygotowanie, żeby mogły się nim posługiwać także osoby, które posługują się wyłącznie klawiaturą, lub innymi, niestandardowymi urządzeniami do obsługi komputera. Interfejs powinien być także tak przygotowany, żeby korzystanie z niego było oczywiste, a operacje odwracalne. Nie ma nic gorszego dla aplikacji www, niż użytkownik, który nie jest pewien, co zrobić, aby osiągnąć oczekiwany rezultat. “Don’t make me think”, najważniejsza reguła budowy interfejsu.

Zanim przejdę do meritum krótkie wprowadzenie: rozwijamy i sprzedajemy system ecommerce. W tym systemie dostępne są różne produkty. Jak wiadomo, produkt, np. koszulka, ma pewne cechy, które są stałe (np. materiał), oraz takie, które mogą się zmieniać bez wpływu na ogólną charakterystykę produktu, np. rozmiar. Te pierwsze cechy nazywamy (tj: w firmie nazywamy) atrybutami, te drugie - opcjami. Koniec teorii.

Produkt może mieć więcej niż jedną opcję, a jedna opcja prawie zawsze ma więcej niż jedną dostępną wartość. Koszulki, oprócz rozmiaru, mogą mieć także opcję koloru. Produkt, który ma określoną wartość opcji, nazywamy wariacją. Jeżeli koszulka ma dwa dostępne rozmiary: mały i duży, oraz dwa kolory: zielony i czerwony, to łącznie ma 4 wariacje: mała zielona, mała czerwona, duża zielona, duża czerwona. Oczywistym jest (khe, khe ;)), że nie wszystkie wariacje zawsze występują w sklepie, czy nawet istnieją. Przełączanie wariacji realizowane jest przez zestaw dropdownów (patrz obrazek po prawej). Jeżeli wariacja dla danej kombinacji koloru i rozmiaru nie istnieje, w stosownym miejscu na stronie wyświetlany jest napis “wariacja niedostępna”.

Rozwiązanie wydaje się proste i eleganckie, ale tylko wtedy, gdy (A) dostępnych wariacji jest więcej niż niedostępnych, oraz (B) wariacje są niedostępne tylko czasowo. Oba te warunki zawodzą przy sklepach, które mają sezonowe kolekcje i pewność, że towar po wyprzedaniu już nie wróci. Dobrym pomysłem jest więc nie wyświetlać niedostępnych wariacji - czyli uniemożliwiać klientowi takie ustawienie dropdownów, które w wyniku daje “wariacja niedostępna”

Od strony technicznej sprawa jest prosta: po zmianie ustawienia pierwszego dropdowna (np.: kolor) badamy, jakie rozmiary są dostępne dla tego koloru, i usuwamy z drugiej listy wszystkie, które są niedostępne. Po wybraniu rozmiaru robimy to samo dla kolorów itp.

I wszystko byłoby super, gdyby nie to, że użytkownik nie ma pojęcia, że za jego plecami odbywają się jakieś podmiany list. Jeżeli np. produkt ma dostępne wariacje: (A, 1), (A, 2), (B, 1), (B, 3) ; wariacje (A, 3) i (B, 2) są niedostępne, a wariacją domyślną (czyli domyślnym ustawieniem dropdownów) jest (A,2), to klient:

nie jest świadomy istnienia opcji wariacji B, dopóki nie zmieni drugiej opcji na 1
dojście do wariacji(B, 3) wymaga: przełączenia 2 na 1, przełączenia A na B, przełączenia 1 na 3
i nawet wtedy nie mamy pewności, czy wszystkie kombinacje zostały wyczerpane… a możemy jeszcze mieć wariację (C, 4), która w ogóle będzie niedostępna - nie z powodów braków magazynowych, ale niemożności ustawienia dropdownów w odpowiedniej pozycji!

No to jak to rozwiązać? Przecież klient musi jakoś móc wybrać opcje. Ano, trzeba niestety pożegnać się z klasycznym formularzem i przejść na rozwiązanie w pełni javascriptowe. Na przykład takie:

http://www.gap.com/browse/product.do?cid=15673&pid=431909

Prawda, że ładnie i przejrzyście? Szkoda tylko, że nie działa bez JavaScriptu…

ColdFusion - utracone hasło

admin — Mon, 12 May 2008 11:42:25 +0000

Zapisuję to sobie tutaj, bo za każdym razem muszę szukać w sieci

Metoda

1. Lokalizujemy plik neo-security.xml (jeżeli mamy CF zainstalowane na domyślnej ścieżce, to będzie w c:\CFusionMX7\lib\)

2. Szukamy ciągu:

name='admin.security.enabled'>
value='true'/>
>

3. Zamieniamy wartość na ‘false’

4. Zapisujemy i restartujemy serwer CF

Voila!

SQL Subselect - parę słów o wydajności

admin — Thu, 08 May 2008 11:38:14 +0000

Trafiłem ostatnio na ciekawy wpis na blogu Krisa, traktujący o problemach związanych z wydajnością SQL subselect w dużych bazach (a przynajmniej dużych jak na aplikacje internetową). Temat dla mnie również ciekawy, ponieważ nasza aplikacja ma poważne problemy z wydajnością pojawiające się przy rozroście bazy danych, i część tych problemów jest związana z bazą danych.

Podejście Krisa - polegające na złamaniu postaci normalnej poprzez utworzenie kolumn pomocniczych z pewnością - poprawiło wydajność, ale budzi we mnie niepokój. Spreparowałem więc sobie zestaw danych wejściowych w celu przeprowadzenia własnego eksperymentu…

Jako podstawy użyłem prostego zestawu tabel:

Nie mam dostępu do PosgreSQL-a, ale wszystkie testy wykonałem na MySQL (5.0, InnoDB) i MSSQL 2000.

Indeksy:

users.id (primary)
users.age
user_language.userId
user_language.languageId
user_language.languageId, user_language.userId

Ilość rekordów:

users - 900 000, languages - 12, user_language - 2 700 000 (3 języki na użytkownika)

WAŻNE! Obie bazy były uruchamiane na różnych maszynach! MySQL pracował na lokalnym komputerze (Pentium 4, 3.2Ghz, 1GB RAM + kupa dodatkowych programów, np. WinAmp w tle), SQL Server na maszynie zdalnej (Xeon 3.2Ghz, 2GB RAMu i w zasadzie tylko MSSQL). Nie można więc porównywać wyników uzyskanych na MySQL i MSSQL.

Druga sprawa: SQL Server był za szybki, żeby sensownie mierzyć czas Ale korzystając z opcji “Execution Plan” SQL Query Analyzera mogę mierzyć szybkość względną zapytania, gdzie 100% = szybkość wykonania wszystkich przedstawionych zapytań.

1. Prosty, podstawowy test: wyszukiwanie ilości osób o określonym wieku:

SELECT COUNT(*) FROM users u WHERE age > 56;

czasy wykonania: MySQL: 0.28, 0.03, 0.03 sekund, SQL Server: 0.35%

SELECT count(*) FROM users u WHERE age < 42;

czasy wykonania: MySQL: 2.31, 0.30, 0.30 sekundy, SQL Server: 3.35%

2. Teraz pora na trochę bardziej złożone zapytanie, wzorowane dokładnie na zapytaniu Krisa:

SELECT COUNT(*)
FROM users u
WHERE
age < 50
AND (
SELECT count(*)
FROM user_language l
WHERE l.languageId=4 AND l.userId=u.id
) = 1;

czasy wykonania: MySQL: 200.66, 186.50, 186.42 sekund, SQL Server: 18.04%

Szczerze mówiąc, trochę to zapytanie dla mnie było dziwne. Po pierwsze, użycie funkcji COUNT() dla sprawdzenia, czy istnieje rekord jest w pewnym sensie nadużycie. Po drugie, złączenie w podzapytaniu z tabelą nadrzędną też nie jest najlepszym pomysłem - wymusza wykonanie zapytania wewnętrznego dla każdego potencjalnie pasującego rekordu.

Moim następnym pomysłem było pozbycie się ww. wad:

SELECT COUNT(*) FROM users u WHERE age < 50 AND id IN (SELECT userId FROM user_language l WHERE l.languageId=4);

czasy wykonania: MySQL: 172.88, 190.06, 176.76 sekund, SQL Server: 15.42%

Szczerze mówiąc - zdębiałem. Powinienem dostać spory przyrost wydajności, a tym czasem MySQL totalnie olał moje modyfikacje (6% szybciej, a w SQL Serverze uzyskałem około 15%)… zacząłem szukać przyczyny, i wykonałem coś takiego:

SELECT count(*) FROM users u WHERE id IN (SELECT userId FROM user_language l WHERE l.languageId=4);

czasy wykonania: MySQL: 25.81, 25.72, 25.27 sekund, SQL Server: test nie został przeprowadzony

Usunięcie warunku dla wieku dało tak olbrzymi przyrost wydajności! Zupełnie nie rozumiem, co się wydarzyło, ale zacząłem się zastanawiać, jak w takim razie umieścić warunek wieku, i wymyśliłem coś takiego:

SELECT count(*) FROM users u WHERE id IN (SELECT id FROM users WHERE age < 50) AND id IN (SELECT userId FROM user_language l WHERE l.languageId=4);

czasy wykonania: MySQL: 29.97, 30.88, 30.41 sekund, SQL Server: 31.38%

W MySQL użycie dwóch podzapytań działa znacznie lepiej, niż użycie jednego i warunku dla WHERE. Przyczyny są dla mnie na razie tajemnicą ;). SQL Server zadziałał zgodnie z oczekiwaniami, tzn: wydajność poważnie (dwukrotnie!) spadła.

3. Trochę zirytowany podzapytaniami, a w szczególności zachowaniem MySQ, na sam koniec zostawiłem sobie testy z wykorzystaniem zwykłych złączeń

SELECT count(*) FROM users u, user_languages l WHERE l.userId = u.id AND l.languageId = 4 AND u.age < 50;

Czas wykonania: MySQL: 4.08, 4.11, 4.02 sekund. SQL Server: 15.72%

MySQL znacznie szybciej obsługuje zwykłe złączenie niż podzapytania! Przyrost wydajności był imponujący. Natomiast dla SQL Servera użycie złączenia wymagało mniej-więcej tyle samo wysiłku co użycie podzapytania (w najszybciej wersji). Spróbowałem jeszcze odrobinę przyspieszyć zapytanie:

SELECT count(*) FROM users u LEFT JOIN user_language l ON l.userId = u.id WHERE l.languageId = 4 AND u.age < 50;

Czas wykonania: MySQL: 3.86, 3.75, 3.88. SQL Server: 15.72%

Zamiana zwykłego złączenia na lewe złączenie przyspieszyła odrobinę zapytanie - o ok. 3% dla MySQL. SQL Server w ogóle nie zarejestrował zmian: plany wykonania obu zapytań nie różnią się.

Wnioski:

po pierwsze, obsługa podzapytań w MySQL jest bardzo wolna. Jeżeli można - należy jej unikać, korzystając ze złączeń.

po drugie - zapomnij o “przenaszalnych” aplikacjach między różnymi silnikami baz danych. SQL może i jest taki sam (lub podobny), ale sposób jego interpretacji i optymalizacji - zupełnie różny. Zupełnie inaczej optymalizuje się zapytanie dla MySQL, a inaczej dla SQL Servera.