🚀 go-pugleaf

W dniu piątek, 30 stycznia 2015 14:19:18 UTC+1 użytkownik Marek napisał:
> Witam,
> 
> Na etapie projektu powstała tabela
> 
> CREATE TABLE tabela
> (
>      tabela_id SERIAL PRIMARY KEY,
> 
>      pola...
> );
> 
> Jednakże okazało się iż tabela ta ma mieć dodatkowe pola zarówno 
> informacyjna jak i czasem biorące udział w wyszukiwaniu. Pól będzie 
> przybywać i mają być definiowane na bieżąco. Typ nieprzewidywalny - 
> niektóre tekstowe, niektóre liczbowe. Pomyślałem zatem, że mógłbym 
> wykorzystać pole typu tablicowego
> 
> CREATE TABLE tabela
> (
>      tabela_id SERIAL PRIMARY KEY,
> 
>      pola...
>      uniwersalne text[];
> );
> 
> Zapis qusi-pól wyglądałby tak, że w polu "uniwersalne" trzymałbym 
> wartości. Kłopot w tym, że PostgreSQL nie ma tablic asocjacyjnych więc 
> musiałbym się posiłkować tabelą słownikową konwertującą nazwę na indeks:
> 
> CREATE TABLE name_to_index
> (
>      name_to_index_id SERIAL PRIMARY KEY,
> 
>     nazwa_pola varchar(100), --nie indeksowane bo tabela będzie miała do 
> ok 20 rekordów
>     indeks_odpowiadajacy_w_polu_uniwersalne int
> );
> 
> Oczywiście w w plpgsql napisałbym funkcję symulującą dostęp do tablicy 
> asocjacyjnej. Czy taka ideologia jest poprawna? Da się to lepiej 
> zorganizować?
> 
> Czy da się indeksować w tablicy np. indeks 4 i 10ty np.?
> 
> -- 
> Pozdrawiam,
> Marek



Wolałbym bardziej praktyczny opis problemu np:

masz tablę t1

id  p1 p2
-------------
1  a111 a222
2  b111 b222
3  c111 c222


i teraz chcesz aby do tej t1 user sobie utowrzył dowolną kombinację indeksów
do pól np:

szukaj p2+p1
szukaj p1+p2

o to chodzi?

Czy może user tworzy sobie własne pole p3, dodaje tam dane
i teraz musi być możliwość dowolnego zaindeksowania pól t1 włącznie
z dodanym polem p3 i oczywiście możliwość szukania danych wykorzystując utworzone przez usera dowolne kombinacje indeksacji pól w t1?

Andrzej.

W dniu 2015-02-03 o 10:44, nkab@toya.net.pl pisze:


> Czy może user tworzy sobie własne pole p3, dodaje tam dane
> i teraz musi być możliwość dowolnego zaindeksowania pól t1 włącznie
> z dodanym polem p3 i oczywiście możliwość szukania danych wykorzystując utworzone przez usera dowolne kombinacje indeksacji pól w t1?

Dokładnie o to mi chodziło :-)

Najprościej byłoby dodać pole p3 w trakcie działania aplikacji ale to 
nie jest "bazodanowe" podejście. Zakłada się zazwyczaj, że tabela ma 
mieć N pól, a jeśli trzeba N+1 to programista musi to oprogramować. Jest 
to spore ograniczenie, które chciałbym w możliwie elegancki sposób 
obejść. Chciałbym tak napisać aplikację aby użytkownik sam sobie dodawał 
co mu potrzebne.

-- 
Pozdrawiam,
Marek

W dniu wtorek, 3 lutego 2015 23:50:54 UTC+1 użytkownik Marek napisał:
> W dniu 2015-02-03 o 10:44, nkab@toya.net.pl pisze:
> 
> 
> > Czy może user tworzy sobie własne pole p3, dodaje tam dane
> > i teraz musi być możliwość dowolnego zaindeksowania pól t1 włącznie
> > z dodanym polem p3 i oczywiście możliwość szukania danych wykorzystując utworzone przez usera dowolne kombinacje indeksacji pól w t1?
> 
> Dokładnie o to mi chodziło :-)
> 
> Najprościej byłoby dodać pole p3 w trakcie działania aplikacji ale to 
> nie jest "bazodanowe" podejście. Zakłada się zazwyczaj, że tabela ma 
> mieć N pól, a jeśli trzeba N+1 to programista musi to oprogramować. Jest 
> to spore ograniczenie, które chciałbym w możliwie elegancki sposób 
> obejść. Chciałbym tak napisać aplikację aby użytkownik sam sobie dodawał 
> co mu potrzebne.
> 
> -- 
> Pozdrawiam,
> Marek

Takie podejście jest amatorskie aczkolwiek możliwe
do zrealizowania, ale pomyśl - dla każdego usera jego
prywatny indeks na serwerze, do tego jeszcze niezliczona
ilość wziętych z księżyca pól.




W php klucz indeksowy możesz włożyć do zmiennej:

$MyKey="(p2,p3,p1)";
mysql_query("CREATE INDEX nowy_index ON tabela $MyKey");




Andrzej.

W dniu 2015-02-04 o 10:46, nkab@toya.net.pl pisze:
> W dniu wtorek, 3 lutego 2015 23:50:54 UTC+1 użytkownik Marek napisał:
>> W dniu 2015-02-03 o 10:44, nkab@toya.net.pl pisze:
>>
>>
>>> Czy może user tworzy sobie własne pole p3, dodaje tam dane
>>> i teraz musi być możliwość dowolnego zaindeksowania pól t1 włącznie
>>> z dodanym polem p3 i oczywiście możliwość szukania danych wykorzystując utworzone przez usera dowolne kombinacje indeksacji pól w t1?
>>
>> Dokładnie o to mi chodziło :-)
>>
>> Najprościej byłoby dodać pole p3 w trakcie działania aplikacji ale to
>> nie jest "bazodanowe" podejście. Zakłada się zazwyczaj, że tabela ma
>> mieć N pól, a jeśli trzeba N+1 to programista musi to oprogramować. Jest
>> to spore ograniczenie, które chciałbym w możliwie elegancki sposób
>> obejść. Chciałbym tak napisać aplikację aby użytkownik sam sobie dodawał
>> co mu potrzebne.
>>
>> --
>> Pozdrawiam,
>> Marek
>
> Takie podejście jest amatorskie aczkolwiek możliwe
> do zrealizowania, ale pomyśl - dla każdego usera jego
> prywatny indeks na serwerze, do tego jeszcze niezliczona
> ilość wziętych z księżyca pól.
>
>
>
>
> W php klucz indeksowy możesz włożyć do zmiennej:
>
> $MyKey="(p2,p3,p1)";
> mysql_query("CREATE INDEX nowy_index ON tabela $MyKey");
>
>
>
>
> Andrzej.
>
Nie macie pojęcia, albo mylicie coś. Indeks jest zakładany na bazie 
administracyjnie, to o czym mówicie to filtry. Ktoś zaproponował podejście 
tekstowe, tu też można zrobić indeksy (swego czasu rozwinęło się to w DBF - 
stare jak i historia baz). Ma to sens (np. xml - ale nie na GB danych)

-- 
Artur
0 weeks 1 day 13 hours 57 minutes 42 seconds and 16 milliseconds.
"pl.comp.bazy-danych"

W dniu środa, 4 lutego 2015 19:11:13 UTC+1 użytkownik artiun napisał:

> Nie macie pojęcia, albo mylicie coś. Indeks jest zakładany na bazie 
> administracyjnie, to o czym mówicie to filtry. Ktoś zaproponował podejście 
> tekstowe, tu też można zrobić indeksy (swego czasu rozwinęło się to w DBF - 
> stare jak i historia baz).

Chłopak się uczy i chce jak najwięcej poznać więc podsuwam mu
rozwiązanie.
Prędzej czy później i tak dojdzie do wniosku, że to pomyłka.

Sam z przyzwyczajenia stosuję indeksy mimo, że wystarczyłoby
zwykłe filtrowanie.

> Ma to sens (np. xml - ale nie na GB danych)
> 

Według mnie właśnie na GB danych ma sens stosowanie indeksów
oczywiście ich odświeżanie przy insertach/apdejtach jest
czasochłonne ale przy szukaniu są naprawdę błyskawiczne.

A dżojna robiłeś bez indeksów?

Andrzej.

W dniu 2015-02-04 o 10:46, nkab@toya.net.pl pisze:

> Takie podejście jest amatorskie aczkolwiek możliwe
> do zrealizowania,

No więc właśnie. Jednakże przy braku "profesjonalnej" opcji trzeba sobie 
jakoś radzić. Takie podejście gwarantuje optymalną wydajność i łatwość 
dostępu do tych danych bo
1. Zakładasz pola o takich typach jakich potrzebujesz.
2. Możesz budować indeksy do nich w razie potrzeb, JOINować etc
3. Wszystkie pola są w jednej tabeli więc dostępne w SELECT * bez 
skomplikowanych zapytań.

> ale pomyśl - dla każdego usera jego
> prywatny indeks na serwerze, do tego jeszcze niezliczona
> ilość wziętych z księżyca pól.

Nie, ilość userów nie ma tu znaczenia. Sprawa się upraszcza. Jeśli jeden 
z nich doda pole ceny artykułu w sklepie internetowym, to pozostali będą 
mieli je dostępne i będą mogli wypełniać wartościami dla poszczególnych 
produktów.


-- 
Pozdrawiam,
Marek

W dniu czwartek, 5 lutego 2015 15:42:09 UTC+1 użytkownik Marek napisał:
> W dniu 2015-02-04 o 10:46, nkab@toya.net.pl pisze:

> > ale pomyśl - dla każdego usera jego
> > prywatny indeks na serwerze, do tego jeszcze niezliczona
> > ilość wziętych z księżyca pól.
> 
> Nie, ilość userów nie ma tu znaczenia. Sprawa się upraszcza. Jeśli jeden 
> z nich doda pole ceny artykułu w sklepie internetowym, to pozostali będą 
> mieli je dostępne i będą mogli wypełniać wartościami dla poszczególnych 
> produktów.
> 

No tak ale po dodaniu pola cena, którego jeszcze nie było
trzeba utworzyć indeks, czyli do każdego pola plik indeksowy?

Ja lubię konkrety.

Tu na grupie już była dyskusja na ten temat i moja sugestia
była taka aby utworzyć tradycyjnie tabele hierarchiczne grupujące
treść od ogółu do szczegółu (komputery:piecyki/laptopy/tablety...)
a w każdej wielkie pole na cechy/właściwości, w którym zastosować
zapis typu JSON jak w CSS:  cecha=wartość,
czyli: "cena=123; color=czerwony kształt=wykrzywiony itd"
(tu skrypt musi to w każdym polu ustawiać cechy w tej samej kolejności,
każda nowa cecha dopisywana na końcu [co z literówkami]).

Radzę sprawdzać w testach czy będą używane indeksy.
Z dużym prawdopodobieństwem nie będą.

Andrzej.

Zapomniałem o jeszcze czymś ważnym.

Czy zdajesz sobie sprawę jakie chamstwo
grasuje w internecie?

Andrzej.

W dniu 2015-02-06 o 09:49, nkab@toya.net.pl pisze:
> Zapomniałem o jeszcze czymś ważnym.
>
> Czy zdajesz sobie sprawę jakie chamstwo
> grasuje w internecie?

Masz na myśli, że ktoś złośliwie będzie dodawał pola? To akurat nie ma 
znaczenia również gdyż mowa jest o części redakcyjnej CMS. Sporadycznie 
będą powstawać nowe właściwości.


-- 
Pozdrawiam,
Marek

W dniu 2015-02-06 o 09:44, nkab@toya.net.pl pisze:

>
> No tak ale po dodaniu pola cena, którego jeszcze nie było
> trzeba utworzyć indeks, czyli do każdego pola plik indeksowy?

Nie, tylko do tych pól, przy których tworzeniu kliknie się opcję "utwórz 
indeks" albo drugi scenariusz: jeśli dane pole ma być kluczem obcym do 
innej tabeli, to aplikacja sama wymusi utworzenie indeksu. To żaden problem.

> Tu na grupie już była dyskusja na ten temat i moja sugestia
> była taka aby utworzyć tradycyjnie tabele hierarchiczne grupujące
> treść od ogółu do szczegółu (komputery:piecyki/laptopy/tablety...)
> a w każdej wielkie pole na cechy/właściwości, w którym zastosować
> zapis typu JSON jak w CSS:  cecha=wartość,
> czyli: "cena=123; color=czerwony kształt=wykrzywiony itd"
> (tu skrypt musi to w każdym polu ustawiać cechy w tej samej kolejności,
> każda nowa cecha dopisywana na końcu [co z literówkami]).
>
> Radzę sprawdzać w testach czy będą używane indeksy.
> Z dużym prawdopodobieństwem nie będą.

Z praktyki wiem, że będą. Np. zdarzyło się iż klient zażyczył sobie w 
trakcie działania aplikacji dorobienia powiązania karty katalogowej 
produktu z instrukcją obsługi (która nie zawsze istniała). I kilka 
podobnych przypadków. Wcale to nie takie rzadkie sytuacje. Tak więc 
notacja a'la JSON raczej nie wchodzi w grę.

-- 
Pozdrawiam,
Marek

Dnia Wed, 11 Feb 2015 00:35:03 -0800 (PST), nkab@toya.net.pl napisał(a):


> mało ludzi wie do czego są te indeksy i określenie indeks to za mało,
> no i dlaczego to to nazywają indeks.

Co to za brednie? Dlaczego robisz projekcje swojej niewiedzy na wiekszosc? Jestem gotow
sie zalozyc, ze 90% uzytkownikow tej grupy wie co to indeks i czemu on sluzy. A jewsli Ty
nie wiesz lub wiesz o tym malo to moze warto doczytac?

http://en.wikipedia.org/wiki/Database_index
 
> PS.
> Fajny masz nick ale ta twoja retoryka sugeruje,
> że działasz na czyjeś zlecenie.

Tak, ruscy go kupili i ma za zadanie zniszczyc hamerykanskie sily zbrojne zakladajaxc
bledne indeksy na tabeli ze wspolrzednymi ataku rakietowego typu ziemia-ziemia. Przez taki
zabieg po pierwszej salwie od ruskich hamerykanski system odpali zapytanie, ktore wykona
sie zbyt wolno i bedzie po ptokach.

-- 
pozdro
R.e.m.e.K

PS. Chętnie pomagam, ale żeby pomóc
trzeba aby druga strona też znała podstawy
i język w którym opiszę mu rozwiązanie
jego problemu.

W dniu 2015-02-12 o 10:34, nkab@toya.net.pl pisze:
> Nie, id to sztuczny numer rekordu a indeks w pliku indeksowym
> to fizyczny adres na dysku. Dyskowy system operacyjny (DOS) wie,
> którą głowicę czytającą dysk uruchomić, na którym krążku magnetycznym,
> na który sektor się ma ustawić głowica...

Na dysku? Już nawet w DOS-ie w pewnym momencie przestało to być prawdą, 
bo dyski fizycznie były inaczej skonstruowane, a BIOS dostawał ich 
wirtualną adresację (bo nie był w stanie zaadresować takiej ilości 
sektorów). Więc choćby z tego powodu to nieprawda.

A jeśli już mówić o adresie, to nawet w DBF był to numer rekordu (lub 
przesunięcie w ramach danej tabeli - pliku DBF), a nie adres na dysku.

> Indeksy są dla zawodowców amatorom wystarczy order by.

Doznałem olśnienia - już wiem czemu jest tylu amatorów na świecie :>.

> Programista baz danych nie używa id, dla zawodowca id nie istnieje.
> Id jest dla administratora bazy danych, daje informacje, że były
> usuwane rekordy.

Czy zawodowiec to taki gość, który doznaje zawodu, bo (jak rozpatruję 
sprawę niżej) ktoś mu usunął rekord/wiersz/krotkę, a on biedny nie wie 
co teraz z tym zrobić?

> id nick
> --------------
> 1  R.E.M.E.K
> 2  nkab
> 3  MM
> 4  MAREK
>
> i teraz ktoś bez twojej wiedzy usunął nkab, co zrobisz
> gdy w drugiej tabeli masz posty do tych ników połączonych
> poprzez id, no co zrobisz?

Widzisz, takie rzeczy to były możliwe tylko w DBF i podobnych systemach 
(gdzie pojęcie "system" jest nadużyciem w ich wypadku) obsługi baz 
danych. Obecnie RDBMS (Relationa DataBase Managament System - czyli po 
naszemu system zarządzania relacyjną bazą danych), jeśli tylko 
zdefiniuje mu się więzy integralności danych nie dopuści do takiej 
sytuacji. Owe więzy integralności (chyba od naszej ostatniej dyskusji 
nie doczytałeś nic na ten temat) polegają w uproszczeniu na tym, że 
RDBMS posiada informację, że rekordy z Twojej przykładowej tabeli są 
powiązane z inną tabelą i można je usunąć jedynie wspólnie (jeden z 
przypadków) albo tzw. nadrzędny rekord można usunąć jedynie, kiedy 
wszystkie powiązane z nim rekordy w dodatkowej tabeli zostaną usunięte 
wcześniej (oczywiście nie dotyczy to tylko usuwania i nie jest to jedyny 
sposób zapewnienia integralności, ale nie chcę komplikować).

 > Napisz koledze M.M. o indeksach tak aby on to
 > zrozumiał, żeby się połapał, że jak da:
 >
 > SELECT nick from t1       (bez indeksów) to da mu:
 >
 > R.E.M.E.K
 > nkab
 > MM
 > MAREK
 >
 > a po dodaniu indeksu dla pola nick
 >
 > SELECT nick from t1      (z indeksami) da mu:
 >
 > MAREK
 > nkab
 > MM
 > R.E.M.E.K
 >
 > i nie ma tu ORDER BY a jednak są w kolejności
 > alfabetycznej

To ja ostrożnie zapytam - w jakim RDBMS? Nie znam PostgreSQL, ale w dość 
dobrze znanym mi MSSQL (lub SQL Server - jak kto woli) dodanie 
poleceniem *insert* zgodnie z powyższą, przypadkową kolejnością może ale 
nie musi dla *select* zwrócić w kolejności dodawania. Bo ta kolejność 
jest z definicji przypadkowa, co obejmuje też przypadek, że będzie 
akurat kolejnością dodawania.

Co więcej - w MSSQL nie trzeba podawać w zapytaniu indeksów, bo jeśli 
takowe są założone dla tabeli, to optymalizator silnika serwera SQL je 
wykorzysta (o ile będzie to opłacalne). Co więcej - potrafi też sobie 
poradzić z wykorzystaniem indeksu złożonego (czyli p1 + p2) dla 
zaprezentowania w kolejności zgodnej z jednym z pól wchodzących w jego 
skład. Pomijam już fakt, że w jego przypadku indeksy tylko w jednym 
przypadku wskazują na położenie wiersza, a w pozostałych, gdy jest 
indeks klastrowy na tabeli, wskazują na wartość tego indeksu.

Indeksy to już od dłuższego czasu nie pliki (bo baza danych jest 
plikiem). To po prostu zbiory danych (danymi są indeksy), zazwyczaj 
(zależy do RDBMS) niezajmujące spójnego obszaru.

-- 
PaSkol (paskol.robi.to)

W dniu 12.02.2015 o 16:21, IDKrzych pisze:

> W SQL by mieć posortowane dane TRZEBA dodać klauzulę ORDER BY.
> I koniec - nie ma wyjątków.
> Indeksy też nic do tego nie mają. I nie do tego służą.
> Indeksy nie służą do sortowania tylko do wyszukiwania i wyszczególniania
> podzbiorów na podstawie zadanych warunków (a precyzyjniej do
> usprawnienia tych czynności - bez indeksów działa to dużo wolniej).
>

Oczywista sprawa, w modelu relacyjnym kolejność wierszy, a nawet pól nie 
jest ważna!!! To, że baza zwraca w kolejności wprowadzenia, czy czasem 
posortuje (bo DISTINCT czy GROUP BY tego wymaga, żeby go zrobić) to jest 
efekt uboczny!
Zwykły UPDATE zaburzy kolejność danych zwracanych przez select * FROM 
tabela.


Prosty test (PostgreSQL):




test=> select * from test;
  id | opis
----+------
   1 |    2
   2 |    2
   3 |    2
   4 |    2
   5 |    2
   6 |    2
   7 |    2
   8 |    2
   9 |    2
  10 |    2
  11 |    2
  12 |    2
  13 |    2
  14 |    2
  15 |    2
  16 |    2
  17 |    2
  18 |    2
  19 |    2
  20 |    2
(20 rows)

test=> update test set opis=3 where id=6;
UPDATE 1
test=> select * from test;
  id | opis
----+------
   1 |    2
   2 |    2
   3 |    2
   4 |    2
   5 |    2
   7 |    2
   8 |    2
   9 |    2
  10 |    2
  11 |    2
  12 |    2
  13 |    2
  14 |    2
  15 |    2
  16 |    2
  17 |    2
  18 |    2
  19 |    2
  20 |    2
   6 |    3
(20 rows)





-- 
Cezary Grądys
czarekgr@wa.onet.pl

W dniu sobota, 14 lutego 2015 08:01:54 UTC+1 użytkownik Cezary Grądys napisał:

Nadal nie wiesz o co chodzi z indeksami.
Te twoje listingi pokazują, że zapytanie nie używa indeksu!
Uaktywnij indeks i dopiero zobaczysz efekt .

Andrzej.

W dniu poniedziałek, 16 lutego 2015 09:23:39 UTC+1 użytkownik nk...@toya.net.pl napisał:
> W dniu sobota, 14 lutego 2015 08:01:54 UTC+1 użytkownik Cezary Grądys napisał:
> 
> Nadal nie wiesz o co chodzi z indeksami.
> Te twoje listingi pokazują, że zapytanie nie używa indeksu!
> Uaktywnij indeks i dopiero zobaczysz efekt .
> 


Sorry, się pośpieszyłem.
Po prostu w MySQL ten numer z gwiazdką nie przechodzi.
Jeśli w postgre tak to działa ja na twoim rysunku no to rzeczywiście
to działa tak jak powinno! Czyli postgre jest lepszym systemem.

Jeszcze raz sorry.

Andrzej.

W dniu 2015-02-16 o 21:23, PaSkol pisze:
/ciach/
Że też chce Ci się uprawiać tą spaloną bzdurami i życzeniowym podejściem 
ziemię...

Przecież gość udowdnił po raz kolejny swoją totalną ignorancję i olewa 
wszystko co się do niego pisze. On wie lepiej.

Tylko tu kaganek (oświaty) nie wystarczy, tu trzeba napalm spuścić aby 
wypalić do cna ten chory sen pijanego idioty.

A teraz zgodnie z podejściem nkaba; ja tam nie wiem, ale jestem 
przekonany, że inaczej się nie da, bo tak jak mi sie wydaje jest 
najlepiej na świecie!

-- 
wloochacz

W dniu 2015-02-17 o 08:44, wloochacz pisze:
> W dniu 2015-02-16 o 21:23, PaSkol pisze:
> /ciach/
> Że też chce Ci się uprawiać tą spaloną bzdurami i życzeniowym podejściem
> ziemię...
>
> Przecież gość udowdnił po raz kolejny swoją totalną ignorancję i olewa
> wszystko co się do niego pisze. On wie lepiej.

Ja tam go nawracać nie chcę, natomiast mam na uwadze postronnych. Tych 
co są tu obecnie i tych przyszłych co to przypadkiem natrafią na ten 
wątek i przyswoją nieprawdziwe informacje.

Podobno cały ruch antyszczepionkowy wziął się z takiego przypadku, gdy 
jakiś niespełniony naukowiec spreparował badania i napisał esej, który 
udowadniał, ze szczepionki to ZUO. To chyba nawet w jakimś 
profesjonalnym periodyku medycznym wyszło i dopiero potem okazało się, 
że to ściema i periodyk dementował. Ale fakt, że opublikował jest 
faktem, który jest z kolei argumentem, że coś tu jest na rzeczy. O tym, 
że było dementi już niekoniecznie się wspomina. I tak sobie żyje ta 
urban legend narażając świat na wybuch epidemii.

> A teraz zgodnie z podejściem nkaba; ja tam nie wiem, ale jestem
> przekonany, że inaczej się nie da, bo tak jak mi sie wydaje jest
> najlepiej na świecie!

Ja mam na to zawsze dobrą odpowiedź: masz rację - wydaje Ci się ;).

-- 
PaSkol (paskol.robi.to)

On Saturday, February 14, 2015 at 8:01:54 AM UTC+1, Cezary Grądys wrote:
> W dniu 12.02.2015 o 16:21, IDKrzych pisze:
> 
> > W SQL by mieć posortowane dane TRZEBA dodać klauzulę ORDER BY.
> > I koniec - nie ma wyjątków.
> > Indeksy też nic do tego nie mają. I nie do tego służą.
> > Indeksy nie służą do sortowania tylko do wyszukiwania i wyszczególniania
> > podzbiorów na podstawie zadanych warunków (a precyzyjniej do
> > usprawnienia tych czynności - bez indeksów działa to dużo wolniej).
> >
> 
> Oczywista sprawa, w modelu relacyjnym kolejność wierszy, a nawet pól nie 
> jest ważna!!!
Jak to nie jest ważna? Jest ważna dla wydajności w przypadku gdy
zbiory danych są przechowywane na dyskach talerzowych. Choćby z
tego powodu został wprowadzony indeks klastrowy. Kolejność jest
na tyle ważna, że czasami trzyma się 2-3 kopie danych, tylko po to
aby w każdej kopii zachować określony porządek sortowania.


> To, że baza zwraca w kolejności wprowadzenia, czy czasem 
> posortuje (bo DISTINCT czy GROUP BY tego wymaga, żeby go zrobić) to jest 
> efekt uboczny!
> Zwykły UPDATE zaburzy kolejność danych zwracanych przez select * FROM 
> tabela.
Ten przykład dowodzi tylko tego, ze pozwoliłeś bazie na zwrócenie danych
w dowolnym porządku i w dowolnym porządku Ci zwróciła. TO nie ma nic
wspólnego z porządkiem na dysku.

Pozdrawiam

W dniu 2015-02-17 o 21:46, M.M. pisze:
> On Saturday, February 14, 2015 at 8:01:54 AM UTC+1, Cezary Grądys wrote:
>> Oczywista sprawa, w modelu relacyjnym kolejność wierszy, a nawet pól nie
>> jest ważna!!!
> Jak to nie jest ważna? Jest ważna dla wydajności w przypadku gdy
> zbiory danych są przechowywane na dyskach talerzowych. Choćby z
> tego powodu został wprowadzony indeks klastrowy. Kolejność jest
> na tyle ważna, że czasami trzyma się 2-3 kopie danych, tylko po to
> aby w każdej kopii zachować określony porządek sortowania.

Czy można prosić o jakiś link na poparcie tych informacji.

-- 
PaSkol (paskol.robi.to)

On Wednesday, February 18, 2015 at 8:34:12 AM UTC+1, PaSkol wrote:
> W dniu 2015-02-17 o 21:46, M.M. pisze:
> > On Saturday, February 14, 2015 at 8:01:54 AM UTC+1, Cezary Grądys wrote:
> >> Oczywista sprawa, w modelu relacyjnym kolejność wierszy, a nawet pól nie
> >> jest ważna!!!
> > Jak to nie jest ważna? Jest ważna dla wydajności w przypadku gdy
> > zbiory danych są przechowywane na dyskach talerzowych. Choćby z
> > tego powodu został wprowadzony indeks klastrowy. Kolejność jest
> > na tyle ważna, że czasami trzyma się 2-3 kopie danych, tylko po to
> > aby w każdej kopii zachować określony porządek sortowania.
> 
> Czy można prosić o jakiś link na poparcie tych informacji.
> 
> -- 
> PaSkol (paskol.robi.to)

To ogólnie dostępna wiedza. Wpisz w google.

W dniu 2015-02-18 o 11:50, M.M. pisze:
> To ogólnie dostępna wiedza. Wpisz w google.

_Co_ takiego mam wpisać w Google, aby dostać materiał potwierdzający, że 
indeks klastrowy został wprowadzony ponieważ zbiory danych są 
przechowywane na dyskach talerzowych.

-- 
PaSkol (paskol.robi.to)

On Wednesday, February 18, 2015 at 7:36:13 PM UTC+1, PaSkol wrote:
> W dniu 2015-02-18 o 11:50, M.M. pisze:
> > To ogólnie dostępna wiedza. Wpisz w google.
> 
> _Co_ takiego mam wpisać w Google, aby dostać materiał potwierdzający, że 
> indeks klastrowy został wprowadzony ponieważ zbiory danych są 
> przechowywane na dyskach talerzowych.
> 
> -- 
> PaSkol (paskol.robi.to)
Właściwie to się nie tylko dysków talerzowych tyczy... Zawsze, gdy 
wyszukanie danych spod 'losowego' adresu jest znacznie wolniejsze od 
odczytu sekwencyjnego, warto zastanowić się nad reorganizacją
danych w tabelach.

Ja wpisałem tak w google: sql indeks klastrowy

Fragment z pierwszej strony w googlu:

Clustered Index swoją strukturą najbardziej przypomina książkę telefoniczną z ułożonymi alfabetycznie wpisami. Indeks ten nie jest odrębnym obiektem składowanym na dysku twardym. Jego podstawowym zadaniem jest narzucanie tabelom, w jaki sposób mają zapisywać wiersze na kolejnych stronach. Istotną informacją jest fakt, iż po utworzeniu indeksu grupującego, struktura stron tabeli podlega reorganizacji wg wskazań indeksu.

Pozdrawiam

W dniu 2015-02-19 o 14:05, M.M. pisze:
> Właściwie to się nie tylko dysków talerzowych tyczy... Zawsze, gdy
> wyszukanie danych spod 'losowego' adresu jest znacznie wolniejsze od
> odczytu sekwencyjnego, warto zastanowić się nad reorganizacją
> danych w tabelach.

Rzecz w tym, że wybór jest zawsze pomiędzy stertą i uporządkowanym 
ułożeniem danych. Zauważ jednak, że o ile indeks klastrowy przyspiesza 
wyszukiwanie, to koszt jego utrzymania jest duży - wymaga bowiem 
relokacji i to całego wiersza, ponieważ jest de facto porządkiem tabeli, 
a nie "adresów" wierszy w tabeli.

Dlatego najczęściej jest zakładany na narastającej wartości, dzięki 
czemu praktycznie znika problem relokacji (i ów koszt). Każdy kolejny 
wiersz jest dodawany na końcu i pozostaje w zgodzie z indeksem. A 
ponieważ owa narastająca wartość jest zazwyczaj także sztucznym kluczem 
głównym tabeli więc zysk się powiększa - wszelkie złączenia są 
najbardziej wydajne jak to tylko możliwe, bo po dokonaniu złączenia jest 
się właśnie w miejscu, z którego można pobrać dane.

Bywa jednak i tak, że klucz nie jest sztuczny, ale naturalny (np. kod 
paskowy albo jakiś symbol zrozumiały dla człowieka). Wówczas konieczne 
są dodatkowe zabiegi, które pozwolą zachować dużą wydajność wyszukiwania 
po takim indeksie, bo następuje jego defragmentacja oraz rosną puste 
przestrzenie w stronach danych (tych o których mowa w przytoczonym przez 
Ciebie fragmencie).

W temacie indeksu klastrowego należy także nadmienić, że ewentualna 
potrzeba jego relokacji wymusza niepełność stron danych w pliku bazy. W 
każdej musi bowiem zostać trochę miejsca na relokowane wiersze (jeśli 
relokacja jest niewielka, bo czasem kończy się to powstaniem nowej 
strony, a oddaniem dotychczasowej do ponownego użycia).

-- 
PaSkol (paskol.robi.to)

W dniu 2015-02-19 o 22:28, PaSkol pisze:
> W dniu 2015-02-19 o 14:05, M.M. pisze:
>> Właściwie to się nie tylko dysków talerzowych tyczy... Zawsze, gdy
>> wyszukanie danych spod 'losowego' adresu jest znacznie wolniejsze od
>> odczytu sekwencyjnego, warto zastanowić się nad reorganizacją
>> danych w tabelach.
No w końcu! :)
Jak sam zauważyłeś, talerz o który m pisałeś wcześniej nie ma tu nic do 
gadania.

> Rzecz w tym, że wybór jest zawsze pomiędzy stertą i uporządkowanym
> ułożeniem danych. Zauważ jednak, że o ile indeks klastrowy przyspiesza
> wyszukiwanie, to koszt jego utrzymania jest duży - wymaga bowiem
> relokacji i to całego wiersza, ponieważ jest de facto porządkiem tabeli,
> a nie "adresów" wierszy w tabeli.
>
> Dlatego najczęściej jest zakładany na narastającej wartości, dzięki
> czemu praktycznie znika problem relokacji (i ów koszt).
> Każdy kolejny
> wiersz jest dodawany na końcu i pozostaje w zgodzie z indeksem. A
> ponieważ owa narastająca wartość jest zazwyczaj także sztucznym kluczem
> głównym tabeli więc zysk się powiększa - wszelkie złączenia są
> najbardziej wydajne jak to tylko możliwe, bo po dokonaniu złączenia jest
> się właśnie w miejscu, z którego można pobrać dane.
>
> Bywa jednak i tak, że klucz nie jest sztuczny, ale naturalny (np. kod
> paskowy albo jakiś symbol zrozumiały dla człowieka). Wówczas konieczne
> są dodatkowe zabiegi, które pozwolą zachować dużą wydajność wyszukiwania
> po takim indeksie, bo następuje jego defragmentacja oraz rosną puste
> przestrzenie w stronach danych (tych o których mowa w przytoczonym przez
> Ciebie fragmencie).
Dodam coś; i dlatego nie powinno się zakładać indeksów klastrowych na 
typach GUID/UUID - to bez sensu. A ludkowie często tak robią...

> W temacie indeksu klastrowego należy także nadmienić, że ewentualna
> potrzeba jego relokacji wymusza niepełność stron danych w pliku bazy. W
> każdej musi bowiem zostać trochę miejsca na relokowane wiersze (jeśli
> relokacja jest niewielka, bo czasem kończy się to powstaniem nowej
> strony, a oddaniem dotychczasowej do ponownego użycia).

-- 
wloochacz

W dniu 2015-02-20 o 08:28, nkab@toya.net.pl pisze:
> W dniu wtorek, 17 lutego 2015 17:52:52 UTC+1 użytkownik PaSkol napisał:
>> Mogą? One są wdrożone. Sprawdź sobie inne RDBMS oprócz tego, którego
>> używasz. I zapoznaj się z organizacją takiego pliku bazy danych, bo z
>> pewnością nie jest taka, jak sobie wyobrażasz.
>
> Niestety ale to tobie wydaje się - wszystkie bazy danych mają
> oddzielne pliki dla rekordów i osobne dla indeksów.

Tak? A dla ilu baz (RDBMS) to sprawdzałeś? Bo ja dla SQL Serwera i 
(kiedyś) Firebirda oraz Oracla. Wszystkie one mają jeden plik na dane 
bazy (a w nich tabele i indeksy, zapewne przechowywane w stronach) i 
ewentualnie dodatkowe pliki na potrzeby zarządzania bazą (logi 
transakcji czy metadane). Czyli ewidentnie _są_wdrożone_ i tym samym nie 
"wszystkie bazy danych mają oddzielne pliki dla rekordów i osobne dla 
indeksów" (chyba PostgreSQL ma z kolei taką strukturę).

> Przestań literaturę traktować jak jakąś biblię i zacznij
> sam analizować a wszystko będzie się bardziej oczywiste.

Jesteś ostatnią osobą, która może udzielać takich rad, bo sam nie 
dokonałeś żadnej analizy, tylko stwierdziłeś, że skoro jest tak w jednym 
systemie, to jest tak w innych. I w przeciwieństwie do Ciebie nie 
traktuje literatury bezkrytycznie, bo uniemożliwia mi to praktyka w 
jakiej sprawdzam poznane tam teorie. Rzecz w tym, że Ty nawet nie masz 
zamiaru rozpoznawać dowolnego tematu - siadasz i robisz. I potem 
wychodzą takie kwiatki jak ignorowanie i deprecjonowanie "order by".

> Prawdziwa historia była inna - naukowiec pokazał jak można
> zniszczyć własne państwo - zaś ostatnie zadnie dopisał złośliwy
> komuch, który chciał ośmieszyć naukowca.

Już wiem - Ty po prostu nie rozumiesz tego co czytasz, albo po prostu 
masz halucynacje, być może wynikające ze wzburzenia. Ale w tej materii 
jestem laikiem, więc może zgłoś się do specjalisty.

> Ja piszę całe systemy od początku do końca, z których użytkownicy
> są bardzo zadowoleni, ty natomiast zajmujesz tylko małym fragmentem
> tego co ja robię na co dzień. W odróżnieniu od ciebie ja jestem
> profesjonalistą a korzystanie z indeksów to mam w małym paluszku.

Skąd wiesz czym się zajmuję? Skąd przypuszczenie, że zadowolenie 
klientów przekłada się na bycie profesjonalistą. Pani z warzywniaka też 
ma zadowolonych klientów, bo ma dobre ceny jak na jakość towarów jakie 
sprzedaje. Gdzie dowód, że masz indeksy w małym paluszku (chociaż chyba 
się zgodzę, bo z tego co dotychczas napisałeś, raczej nie w głowie). 
Gdzie dowód, że to Ty a nie ja jesteś profesjonalistą.

> Was dwóch wkurza, że jest tu ktoś, kto prostymi metodami przekazuje
> innym swoją wiedzę praktyczną. To was dwóch wkurza, ale mnie to lata
> i powiewa. Złóżcie raport swojemu mocodawcy, że nkab znowu nadaje.
> Z analitykiem  nie wygracie.

Nas dwóch? Mówisz o Wloochaczu? Porównaj sobie te pisane przez Ciebie 
"całe systemy od początku do końca" z jego systemem. Nadal uważasz się 
za profesjonalistę?

I nic Ci nie da wmawianie nam, że prostymi metodami przekazujesz wiedzę 
praktyczną. Ty przekazujesz to co Ci się wydaje. To nie jest _WIEDZA_, 
to jakieś bzdety. I banalnym jest wykazać, że bzdetami są, Ty zaś nie 
jesteś w stanie podać kontrargumentów, które by temu przeczyły.


-- 
PaSkol (paskol.robi.to)

W dniu 2015-02-20 o 11:41, wloochacz pisze:
> Dodam coś; i dlatego nie powinno się zakładać indeksów klastrowych na
> typach GUID/UUID - to bez sensu. A ludkowie często tak robią...

Dokładnie - masakra :).

-- 
PaSkol (paskol.robi.to)

On Thursday, February 19, 2015 at 10:28:54 PM UTC+1, PaSkol wrote:
> W dniu 2015-02-19 o 14:05, M.M. pisze:
> > Właściwie to się nie tylko dysków talerzowych tyczy... Zawsze, gdy
> > wyszukanie danych spod 'losowego' adresu jest znacznie wolniejsze od
> > odczytu sekwencyjnego, warto zastanowić się nad reorganizacją
> > danych w tabelach.
> 
> Rzecz w tym, że wybór jest zawsze pomiędzy stertą i uporządkowanym 
> ułożeniem danych. 
No tak.

> Zauważ jednak, że o ile indeks klastrowy przyspiesza 
> wyszukiwanie, to koszt jego utrzymania jest duży - wymaga bowiem 
> relokacji i to całego wiersza, ponieważ jest de facto porządkiem tabeli, 
> a nie "adresów" wierszy w tabeli.
Generalnie, utrzymanie porządku danych na dowolnym nośniku może
być związane z dużym kosztem. Jeśli często wstawiasz rekord o
'losowych wartościach klucza', często usuwasz losowy rekord, często
modyfikujesz wartości rekordu związane z kluczem, to może nawet
baza RAM nie wytrzymać. Nigdy nie spotkałem się z opcją, która
wymusza porządek raz na jakiś czas, np. raz na dobę, albo po
przekroczeniu N modyfikacji - bazy są wyposażone w takie mechanizmy?


> Dlatego najczęściej jest zakładany na narastającej wartości, dzięki 
> czemu praktycznie znika problem relokacji (i ów koszt). 
Lecz im bardziej ten koszt znika, tym mniej taki indeks jest potrzebny :)



> Każdy kolejny 
> wiersz jest dodawany na końcu i pozostaje w zgodzie z indeksem. A 
> ponieważ owa narastająca wartość jest zazwyczaj także sztucznym kluczem 
> głównym tabeli 
W praktyce data często narasta.


> więc zysk się powiększa - wszelkie złączenia są 
> najbardziej wydajne jak to tylko możliwe, bo po dokonaniu złączenia jest 
> się właśnie w miejscu, z którego można pobrać dane.
To przy założeniu, że pozycję rekordu można wyliczyć z wzoru
head + (id - id_poczatkowe) * sizeof(rekord). Jeśli usuniesz jeden
rekord ze środka, to albo:
1) tracisz taką możliwość
2) musisz zmienić wszystkie id własne i obce!



> Bywa jednak i tak, że klucz nie jest sztuczny, ale naturalny (np. kod 
> paskowy albo jakiś symbol zrozumiały dla człowieka). 
Może robię źle, ale zawsze używam klucza int64, robię to z automatu, bez
zastanowienia.


> Wówczas konieczne 
> są dodatkowe zabiegi, które pozwolą zachować dużą wydajność wyszukiwania 
> po takim indeksie, 
Po prostu uaktualnia się indeks btree, hash, czy co tam jeszcze...

> bo następuje jego defragmentacja 
Nie wiem co to jest defragmentacja indeksu.


> oraz rosną puste przestrzenie w stronach danych (tych o których 
> mowa w przytoczonym przez Ciebie fragmencie).
Nie wiem o co chodzi, gdy użyje się narastającego klucza, to
w wyniku usunięcia rekordu, też powstaje 'pusta przestrzeń'.


> 
> W temacie indeksu klastrowego należy także nadmienić, że ewentualna 
> potrzeba jego relokacji wymusza niepełność stron danych w pliku bazy. 
Nie rozumiem.

> W 
> każdej musi bowiem zostać trochę miejsca na relokowane wiersze (jeśli 
> relokacja jest niewielka, bo czasem kończy się to powstaniem nowej 
> strony, a oddaniem dotychczasowej do ponownego użycia).
Też nie rozumiem. 


Chodzi o ulożenie danych w taki sposób, aby był sprzyjający szybkiemu
odczytowi. Czy trzeba wnikać w to, ile pustego miejsca zostaje na
stronie? Chyba normalnie dane zapisuje się pod narastającymi 
wskaźnikami? Ale to wszystko i tak bierze w łeb, gdy dane leżą
na rozproszonych maszynach....

Pozdrawiam

W dniu 2015-02-20 o 17:50, M.M. pisze:
> Nigdy nie spotkałem się z opcją, która
> wymusza porządek raz na jakiś czas, np. raz na dobę, albo po
> przekroczeniu N modyfikacji - bazy są wyposażone w takie mechanizmy?

Takimi indeksami są te MSSQL dotyczące wyszukiwania tekstowego 
(full-text search). We wcześniejszych wersjach trzeba je było 
aktualizować osobno, obecnie chyba jest to automatyczne, ale nie 
potwierdzę w 100% ponieważ nie używam tej funkcjonalności.

>> Dlatego najczęściej jest zakładany na narastającej wartości, dzięki
>> czemu praktycznie znika problem relokacji (i ów koszt).
> Lecz im bardziej ten koszt znika, tym mniej taki indeks jest potrzebny :)

Niekoniecznie, bo indeks ten jest (jak już pisałem) przydatny w 
złączeniach. Natomiast do wyszukiwania (jakiegokolwiek) można zastosować 
indeksy nieklastrowe. W większości przypadków są one wystarczające 
wydajnościowo.

>> więc zysk się powiększa - wszelkie złączenia są
>> najbardziej wydajne jak to tylko możliwe, bo po dokonaniu złączenia jest
>> się właśnie w miejscu, z którego można pobrać dane.
> To przy założeniu, że pozycję rekordu można wyliczyć z wzoru
> head + (id - id_poczatkowe) * sizeof(rekord). Jeśli usuniesz jeden
> rekord ze środka, to albo:
> 1) tracisz taką możliwość
> 2) musisz zmienić wszystkie id własne i obce!

Nie, nie o to chodzi. Szukając klucza o wartości 100, w przypadku 
indeksu klastrowego przeszukiwana jest de facto tabela, tylko że 
wiadomo, iż ona "narasta" czyli trzeba przejść przez max. 100 wierszy. 
To nigdy nie jest wyliczana pozycja m.in. z tego powodu, który podałeś, 
ale także dlatego, że masz pola (kolumny) o dynamicznej wielkości (np. 
varchar), co pozwala upakować na stronie danych więcej tychże danych 
(czasem strona - której wielkość jest przecież stała - ma więcej wierszy 
niż inna strona tej samej tabeli). Dlatego gdy znajdziesz 100, to tuż za 
nim jest cała reszta potrzebnego Ci wiersza. O to mi chodziło, gdy 
pisałem o "miejscu".

Pisząc o Id (bo widzę, że traktujesz je w innym, także występującym po 
taką nazwą znaczeniu) miałem na myśli kolumnę o nazwie Id, a nie 
wewnętrzny (internal) identyfikator wiersza w tabeli. Czyli nie wystąpi 
tutaj konieczność readresacji, bo to wartości klucza.

Tu od razu zastrzegam, że piszę z pamięci, a od pewnego czasu nie siedzę 
zbyt intensywnie w bazach danych, więc mogło mi się już coś zatrzeć w 
pamięci. Co z kolei jest widomym powodem, że pora sobie trochę te 
wiadomości odświeżyć, więc być może wrzucę coś na bloga w tym temacie 
(gdybyż jeszcze ten czas).

>> Bywa jednak i tak, że klucz nie jest sztuczny, ale naturalny (np. kod
>> paskowy albo jakiś symbol zrozumiały dla człowieka).
> Może robię źle, ale zawsze używam klucza int64, robię to z automatu, bez
> zastanowienia.

Zapewne w większości przypadków nie będzie to szczególnie kosztowne. A 
po to mamy tuning bazy danych, aby kiedy już koszt stanie się uciążliwy, 
po prostu ten tuning przeprowadzić.

>> bo następuje jego defragmentacja
> Nie wiem co to jest defragmentacja indeksu.

Dane jak i indeksy (a indeks klastrowy jest przecież integralny z 
danymi) są przechowywane na stronach. Bywa (znów piszę z pamięci, ale 
chyba tak właśnie to działa), że zamiast relokować wiersze lepiej jest 
zostawić część na obecnej stronie, a te wstawiane wrzucić na nową i 
umieścić ją tuż za tamtą w logicznym łańcuchu stron. Układ fizyczny tych 
stron będzie inny niż logiczny, więc mogą być od siebie oddalone w 
rzeczywistym pliku bazy o spory odstęp. Więc jest defragmentacja.

>> oraz rosną puste przestrzenie w stronach danych (tych o których
>> mowa w przytoczonym przez Ciebie fragmencie).
> Nie wiem o co chodzi, gdy użyje się narastającego klucza, to
> w wyniku usunięcia rekordu, też powstaje 'pusta przestrzeń'.

Ta pusta przestrzeń może powstać, kiedy w powyższym przykładzie część 
wierszy pozostaje na stronie, część jest usuwana i przenoszona na inną 
stronę, choć dochodzi np. kilka wierszy. Dlaczego tak się dzieje?

>> W temacie indeksu klastrowego należy także nadmienić, że ewentualna
>> potrzeba jego relokacji wymusza niepełność stron danych w pliku bazy.
> Nie rozumiem.

Otóż strony pozostają niepełne właśnie ze względu na to, że może zajść 
potrzeba dodania pomiędzy znajdujące się na nich wiersze tego, który 
zgodnie z porządkiem powinien być tam umieszczony. I wówczas gdy strona 
nie jest w całości zapełniona, można taki wiersz dorzucić w owo puste 
miejsce (lub relokować w ramach strony istniejące tam wiersze, by 
wstawić ów nowy pomiędzy nie). SQL Serwer ma zdefiniowane jak tą pustą 
przestrzenią zarządzać, więc czasem dokłada do niej wiersze, a czasem z 
tego rezygnuje, jeśli z oszacowań wychodzi mu, że lepiej wstawić 
pomiędzy strony kolejną, a tamto puste miejsce pozostawić na przyszłe 
potrzeby.

> Chodzi o ulożenie danych w taki sposób, aby był sprzyjający szybkiemu
> odczytowi. Czy trzeba wnikać w to, ile pustego miejsca zostaje na
> stronie?

Czasem trzeba, bywa bowiem, że posiadana przestrzeń ma konkretny koszt 
(np. w chmurze) i konieczne staje się odpowiednie dostosowanie owej 
pustej przestrzeni. Jest to nieustanna walka pomiędzy wydajnością i 
zajętością bazy.

> Ale to wszystko i tak bierze w łeb, gdy dane leżą
> na rozproszonych maszynach....

Nie wiem, nie mam doświadczenia w tej materii, o ile rozumiemy 
rozproszenie danych tej samej tabeli czy bazy (czy to byłyby partycje na 
oddzielnych maszynach? tego nie trenowałem).

-- 
PaSkol (paskol.robi.to)

On Friday, February 20, 2015 at 8:15:24 PM UTC+1, PaSkol wrote:
> W dniu 2015-02-20 o 17:50, M.M. pisze:
> > Nigdy nie spotkałem się z opcją, która
> > wymusza porządek raz na jakiś czas, np. raz na dobę, albo po
> > przekroczeniu N modyfikacji - bazy są wyposażone w takie mechanizmy?
> 
> Takimi indeksami są te MSSQL dotyczące wyszukiwania tekstowego 
> (full-text search). We wcześniejszych wersjach trzeba je było 
> aktualizować osobno, obecnie chyba jest to automatyczne, ale nie 
> potwierdzę w 100% ponieważ nie używam tej funkcjonalności.
Przeszukiwanie pełnotekstowe to jeszcze inne zagadnienie.



> >> Dlatego najczęściej jest zakładany na narastającej wartości, dzięki
> >> czemu praktycznie znika problem relokacji (i ów koszt).
> > Lecz im bardziej ten koszt znika, tym mniej taki indeks jest potrzebny :)
> 
> Niekoniecznie, bo indeks ten jest (jak już pisałem) przydatny w 
> złączeniach. Natomiast do wyszukiwania (jakiegokolwiek) można zastosować 
> indeksy nieklastrowe. W większości przypadków są one wystarczające 
> wydajnościowo.
Nie rozumiem dlaczego niekoniecznie. Nie rozumiem też, dlaczego
indeks klastrowy miałby być lepszy w złączeniach niż zwykły.


> 
> >> więc zysk się powiększa - wszelkie złączenia są
> >> najbardziej wydajne jak to tylko możliwe, bo po dokonaniu złączenia jest
> >> się właśnie w miejscu, z którego można pobrać dane.
> > To przy założeniu, że pozycję rekordu można wyliczyć z wzoru
> > head + (id - id_poczatkowe) * sizeof(rekord). Jeśli usuniesz jeden
> > rekord ze środka, to albo:
> > 1) tracisz taką możliwość
> > 2) musisz zmienić wszystkie id własne i obce!
> 
> Nie, nie o to chodzi. Szukając klucza o wartości 100, w przypadku 
> indeksu klastrowego przeszukiwana jest de facto tabela, tylko że 
> wiadomo, iż ona "narasta" czyli trzeba przejść przez max. 100 wierszy.
To zależy od implementacji indeksu. Nie mam bladego pojęcia, jakie 
są implementacje w popularnych bazach. W przypadku wyszukiwania 
binarnego, maksymalna ilość wierszy, które trzeba poddać analizie,
zależy od ilości wszystkich rekordów w tabeli, a nie od wartości klucza.

 
> To nigdy nie jest wyliczana pozycja m.in. z tego powodu, który podałeś, 
> ale także dlatego, że masz pola (kolumny) o dynamicznej wielkości (np. 
> varchar), co pozwala upakować na stronie danych więcej tychże danych
Tak, to dodatkowy powód, ale tylko w pewnych implementacjach. Pole
może mieć stałą dlugość, może zawierać tylko odnośnik do innego
pliku, albo do innej przestrzeni adresowej w tym samym pliku. 
Rozwiązań jest sporo, nie wiem jak to jest rozwiązane w popularnych 
bazach. Tak czy inaczej, rozmowa na ten temat chyba nic istotnego dla 
programisty-użytkownika baz danych nie wnosi?

 
> (czasem strona - której wielkość jest przecież stała - ma więcej wierszy 
> niż inna strona tej samej tabeli). Dlatego gdy znajdziesz 100, to tuż za 
> nim jest cała reszta potrzebnego Ci wiersza. O to mi chodziło, gdy 
> pisałem o "miejscu".
> Pisząc o Id (bo widzę, że traktujesz je w innym, także występującym po 
> taką nazwą znaczeniu) miałem na myśli kolumnę o nazwie Id, a nie 
> wewnętrzny (internal) identyfikator wiersza w tabeli. Czyli nie wystąpi 
> tutaj konieczność readresacji, bo to wartości klucza.
Mam zasadnicze pytanie dla dalszej rozmowy, czy warto tak szczegółową
wiedzę posiadać, czy lepiej traktować indeks, pole, tabelę, klucz, jako
(prawie) czarne skrzynki?


> Tu od razu zastrzegam, że piszę z pamięci, a od pewnego czasu nie siedzę 
> zbyt intensywnie w bazach danych, więc mogło mi się już coś zatrzeć w 
> pamięci. Co z kolei jest widomym powodem, że pora sobie trochę te 
> wiadomości odświeżyć, więc być może wrzucę coś na bloga w tym temacie 
> (gdybyż jeszcze ten czas).
Właśnie, gdy traktujemy bazę jako zestaw czarnych skrzynek, to czasu
mamy więcej.


> >> Bywa jednak i tak, że klucz nie jest sztuczny, ale naturalny (np. kod
> >> paskowy albo jakiś symbol zrozumiały dla człowieka).
> > Może robię źle, ale zawsze używam klucza int64, robię to z automatu, bez
> > zastanowienia.
> 
> Zapewne w większości przypadków nie będzie to szczególnie kosztowne. A 
> po to mamy tuning bazy danych, aby kiedy już koszt stanie się uciążliwy, 
> po prostu ten tuning przeprowadzić.
Mogę poprosić o jakiś przykład, gdy to będzie bardzo kosztowne?


> >> bo następuje jego defragmentacja
> > Nie wiem co to jest defragmentacja indeksu.
> 
> Dane jak i indeksy (a indeks klastrowy jest przecież integralny z 
> danymi) 
Nie wiem co to jest indeks integralny z danymi. Masz na myśli to,
że dane są uporządkowane, więc można zastosować wyszukiwanie
binarne (np. z aproksymacją liniową), więc nie potrzeba żadnych 
dodatkowych informacji? Jeśli tak, to zwróć uwagę, że nie na
wszystkich nośnikach takie wyszukiwanie jest optymalne.

> są przechowywane na stronach. Bywa (znów piszę z pamięci, ale 
> chyba tak właśnie to działa), że zamiast relokować wiersze lepiej jest 
> zostawić część na obecnej stronie, a te wstawiane wrzucić na nową i 
> umieścić ją tuż za tamtą w logicznym łańcuchu stron.
Zależy dlaczego lepiej. Dla przeglądania sekwencyjnego gorzej, ponieważ
trzeba więcej danych przejrzeć. Dla wyszukiwania losowego chyba lepiej,
bo wystarczy jedną stronę wycztać. Dla wstawiania może być lepiej, 
ale pod warunkiem, że zostawi się dużo wolnego miejsca.

> Układ fizyczny tych 
> stron będzie inny niż logiczny, więc mogą być od siebie oddalone w 
> rzeczywistym pliku bazy o spory odstęp. Więc jest defragmentacja.
Ja chyba w ogóle nie rozumiem jak używasz określenia indeks :)
Z tego co piszesz, to po prostu kolejne ( w sensie sortowania ) dane nie
są pod kolejnymi adresami (w sensie sekwencyjnego odczytu).

> 
> >> oraz rosną puste przestrzenie w stronach danych (tych o których
> >> mowa w przytoczonym przez Ciebie fragmencie).
> > Nie wiem o co chodzi, gdy użyje się narastającego klucza, to
> > w wyniku usunięcia rekordu, też powstaje 'pusta przestrzeń'.
> 
> Ta pusta przestrzeń może powstać, kiedy w powyższym przykładzie część 
> wierszy pozostaje na stronie, część jest usuwana i przenoszona na inną 
> stronę, choć dochodzi np. kilka wierszy. Dlaczego tak się dzieje?
> 
> >> W temacie indeksu klastrowego należy także nadmienić, że ewentualna
> >> potrzeba jego relokacji wymusza niepełność stron danych w pliku bazy.
> > Nie rozumiem.
> 
> Otóż strony pozostają niepełne właśnie ze względu na to, że może zajść 
> potrzeba dodania pomiędzy znajdujące się na nich wiersze tego, który 
> zgodnie z porządkiem powinien być tam umieszczony. I wówczas gdy strona 
> nie jest w całości zapełniona, można taki wiersz dorzucić w owo puste 
> miejsce (lub relokować w ramach strony istniejące tam wiersze, by 
> wstawić ów nowy pomiędzy nie). SQL Serwer ma zdefiniowane jak tą pustą 
> przestrzenią zarządzać, więc czasem dokłada do niej wiersze, a czasem z 
> tego rezygnuje, jeśli z oszacowań wychodzi mu, że lepiej wstawić 
> pomiędzy strony kolejną, a tamto puste miejsce pozostawić na przyszłe 
> potrzeby.
To pewnie jest dobry kompromis pomiędzy wydajnym odczytem sekwencyjnym, a
wydajnymi modyfikacjami. Czy postgres też ma coś takiego?



> > Chodzi o ulożenie danych w taki sposób, aby był sprzyjający szybkiemu
> > odczytowi. Czy trzeba wnikać w to, ile pustego miejsca zostaje na
> > stronie?
> 
> Czasem trzeba, bywa bowiem, że posiadana przestrzeń ma konkretny koszt 
> (np. w chmurze) i konieczne staje się odpowiednie dostosowanie owej 
> pustej przestrzeni. Jest to nieustanna walka pomiędzy wydajnością i 
> zajętością bazy.
Rozumiem. Ale też pomiędzy wydajnością modyfikacji a wydajnością 
sekwencyjnego odczytu.



> > Ale to wszystko i tak bierze w łeb, gdy dane leżą
> > na rozproszonych maszynach....
> 
> Nie wiem, nie mam doświadczenia w tej materii, o ile rozumiemy 
> rozproszenie danych tej samej tabeli czy bazy (czy to byłyby partycje na 
> oddzielnych maszynach? tego nie trenowałem).
To jest jeszcze trudniejsze, niż rozstrzyganie czy rozproszenie jest na
poziomie tabeli czy bazy.

Do identyfikacji rekordów można mieć parę uporządkowaną: 
(klucz_wlasny, tabela). Można mieć N maszyn. Można obliczyć numer 
maszyny: i = funkcję hash(klucz_wlasny, tabela) % N.
W ten sposób tabela może być tylko stringiem do obliczania 
numeru maszyny i numeru zbioru danych na danej maszynie. Tabela
jako taka może w ogole nie istnieć.

Tak samo prosto można podejść do indeksów. Do identyfikacji rekordu
w indeksie też wystarczy taka para: (klucz, nazwa_indeksu). Rekordem
indeksu to może być trójka: ( rodzic, lewy, prawy ) - i mamy
drzewo poszukiwań binarnych. 

Niby wszystko pięknie, ale jaka robi się sieczka na takim prostym 
rozwiązaniu? Praktycznie nie ma szans na to, aby wykorzystać pamięc 
cache (w celu przyspieszenia). W dodatku ile jest maleńkich 
transferów po sieci? 

Wniosek z tego taki, że zwykle trzeba wyrzeźbić swoje, specjalistyczne
rozwiązanie i dostosować rozkład danych i do sprzętu, i do algorytmów.

Pozdrawiam

W dniu 2015-02-21 o 12:53, M.M. pisze:
>>>> Dlatego najczęściej jest zakładany na narastającej wartości, dzięki
>>>> czemu praktycznie znika problem relokacji (i ów koszt).
>>> Lecz im bardziej ten koszt znika, tym mniej taki indeks jest potrzebny :)
>>
>> Niekoniecznie, bo indeks ten jest (jak już pisałem) przydatny w
>> złączeniach. Natomiast do wyszukiwania (jakiegokolwiek) można zastosować
>> indeksy nieklastrowe. W większości przypadków są one wystarczające
>> wydajnościowo.
> Nie rozumiem dlaczego niekoniecznie. Nie rozumiem też, dlaczego
> indeks klastrowy miałby być lepszy w złączeniach niż zwykły.

No przecież sam przytoczyłeś:

"...Clustered Index swoją strukturą najbardziej przypomina książkę 
telefoniczną z ułożonymi alfabetycznie wpisami. Indeks ten nie jest 
odrębnym obiektem składowanym na dysku twardym. Jego podstawowym 
zadaniem jest narzucanie tabelom, w jaki sposób mają zapisywać wiersze 
na kolejnych stronach. Istotną informacją jest fakt, iż po utworzeniu 
indeksu grupującego, struktura stron tabeli podlega reorganizacji wg 
wskazań indeksu..."

Więc łącząc jakąś tabelę z tą tabelą po takim indeksie, od razu 
dostajemy też dane, zamiast najpierw dowiedzieć się, gdzie te dane są i 
dopiero po nie sięgnąć.

>> Nie, nie o to chodzi. Szukając klucza o wartości 100, w przypadku
>> indeksu klastrowego przeszukiwana jest de facto tabela, tylko że
>> wiadomo, iż ona "narasta" czyli trzeba przejść przez max. 100 wierszy.
> To zależy od implementacji indeksu. Nie mam bladego pojęcia, jakie
> są implementacje w popularnych bazach. W przypadku wyszukiwania
> binarnego, maksymalna ilość wierszy, które trzeba poddać analizie,
> zależy od ilości wszystkich rekordów w tabeli, a nie od wartości klucza.

Ale tu jest mowa o konkretnym indeksie _klastrowym_ i to w kontekście 
MSSQL-a (ten cytat, który przytaczałeś dotyczy właśnie jego).

>> To nigdy nie jest wyliczana pozycja m.in. z tego powodu, który podałeś,
>> ale także dlatego, że masz pola (kolumny) o dynamicznej wielkości (np.
>> varchar), co pozwala upakować na stronie danych więcej tychże danych
> Tak, to dodatkowy powód, ale tylko w pewnych implementacjach. Pole
> może mieć stałą dlugość

Jeśli ma _stałą_ długość to nie jest varcharem - na tym polega 
właściwość varchara, że nie zajmuje z góry ustalonego miejsca.

> Tak czy inaczej, rozmowa na ten temat chyba nic istotnego dla
> programisty-użytkownika baz danych nie wnosi?

Zależy jakie masz oczekiwania wobec pisanego oprogramowania. Jeśli 
wydajność nie jest tu kluczowa, to można sobie tym głowy nie zawracać. Z 
drugiej strony, jeśli od razu projektujesz bazę wykorzystując taką 
wiedzę, to potem nie będziesz musiał jej reorganizować.

> Mam zasadnicze pytanie dla dalszej rozmowy, czy warto tak szczegółową
> wiedzę posiadać, czy lepiej traktować indeks, pole, tabelę, klucz, jako
> (prawie) czarne skrzynki?

Odpowiedź jest taka sama jak poprzednia.

>> Tu od razu zastrzegam, że piszę z pamięci, a od pewnego czasu nie siedzę
>> zbyt intensywnie w bazach danych, więc mogło mi się już coś zatrzeć w
>> pamięci. Co z kolei jest widomym powodem, że pora sobie trochę te
>> wiadomości odświeżyć, więc być może wrzucę coś na bloga w tym temacie
>> (gdybyż jeszcze ten czas).
> Właśnie, gdy traktujemy bazę jako zestaw czarnych skrzynek, to czasu
> mamy więcej.

Zależy który czas jest dla nas cenniejszy: nasz czy wszystkich 
użytkowników naszego - być może zbyt wolnego - oprogramowania.

>> Zapewne w większości przypadków nie będzie to szczególnie kosztowne. A
>> po to mamy tuning bazy danych, aby kiedy już koszt stanie się uciążliwy,
>> po prostu ten tuning przeprowadzić.
> Mogę poprosić o jakiś przykład, gdy to będzie bardzo kosztowne?

Int64 w stosunku do Int32, jeżeli zakres wartości nie ma szans sięgnąć 
max tego drugiego, jest marnowaniem pamięci potrzebnej na przetwarzanie 
złączeń. Dla Int32 da się załadować więcej tych wartości do cache niż 
przy Int64.

> Nie wiem co to jest indeks integralny z danymi.

To jest właśnie indeks klastrowy - dane w tabeli są układane w 
kolejności odpowiadającej regule indeksu (zgodnie z zacytowanym tekstem).

>> są przechowywane na stronach. Bywa (znów piszę z pamięci, ale
>> chyba tak właśnie to działa), że zamiast relokować wiersze lepiej jest
>> zostawić część na obecnej stronie, a te wstawiane wrzucić na nową i
>> umieścić ją tuż za tamtą w logicznym łańcuchu stron.
> Zależy dlaczego lepiej. Dla przeglądania sekwencyjnego gorzej, ponieważ
> trzeba więcej danych przejrzeć. Dla wyszukiwania losowego chyba lepiej,
> bo wystarczy jedną stronę wycztać. Dla wstawiania może być lepiej,
> ale pod warunkiem, że zostawi się dużo wolnego miejsca.

Wiesz, projektanci baz wybrali nie bez powodu takie "poszatkowane" 
rozwiązanie. Zapewne statystycznie jest ono najlepsze.

>> Układ fizyczny tych
>> stron będzie inny niż logiczny, więc mogą być od siebie oddalone w
>> rzeczywistym pliku bazy o spory odstęp. Więc jest defragmentacja.
> Ja chyba w ogóle nie rozumiem jak używasz określenia indeks :)
> Z tego co piszesz, to po prostu kolejne ( w sensie sortowania ) dane nie
> są pod kolejnymi adresami (w sensie sekwencyjnego odczytu).

Nie mam tyle czasu, aby to dogłębnie wytłumaczyć, a rzecz sprowadza się 
do sposobu reprezentowania danych w samym pliku bazy. Tutaj odsyłam do 
pozycji "Microsoft SQL Server 2008 od środka: Zapytania w języku T-SQL" 
(przedostatnia pozycja działu Literatura na moim blogu). Z tym, że nie 
wiem czy taka wiedza jest Ci potrzebna, jeżeli używasz Posgresa.

>> Otóż strony pozostają niepełne właśnie ze względu na to, że może zajść
>> potrzeba dodania pomiędzy znajdujące się na nich wiersze tego, który
>> zgodnie z porządkiem powinien być tam umieszczony. I wówczas gdy strona
>> nie jest w całości zapełniona, można taki wiersz dorzucić w owo puste
>> miejsce (lub relokować w ramach strony istniejące tam wiersze, by
>> wstawić ów nowy pomiędzy nie). SQL Serwer ma zdefiniowane jak tą pustą
>> przestrzenią zarządzać, więc czasem dokłada do niej wiersze, a czasem z
>> tego rezygnuje, jeśli z oszacowań wychodzi mu, że lepiej wstawić
>> pomiędzy strony kolejną, a tamto puste miejsce pozostawić na przyszłe
>> potrzeby.
> To pewnie jest dobry kompromis pomiędzy wydajnym odczytem sekwencyjnym, a
> wydajnymi modyfikacjami. Czy postgres też ma coś takiego?

Nie wiem, nie znam tej bazy, musiałbyś sprawdzić, wydaje mi się, że to 
baza w której tabele są w plikach, więc tutaj stronicowanie tabeli może 
być inaczej zrealizowane (może nie opłaca się jej stronicować?)

-- 
PaSkol (paskol.robi.to)

On Saturday, February 21, 2015 at 5:41:09 PM UTC+1, PaSkol wrote:
> W dniu 2015-02-21 o 12:53, M.M. pisze:
> >>>> Dlatego najczęściej jest zakładany na narastającej wartości, dzięki
> >>>> czemu praktycznie znika problem relokacji (i ów koszt).
> >>> Lecz im bardziej ten koszt znika, tym mniej taki indeks jest potrzebny :)
> >>
> >> Niekoniecznie, bo indeks ten jest (jak już pisałem) przydatny w
> >> złączeniach. Natomiast do wyszukiwania (jakiegokolwiek) można zastosować
> >> indeksy nieklastrowe. W większości przypadków są one wystarczające
> >> wydajnościowo.
> > Nie rozumiem dlaczego niekoniecznie. Nie rozumiem też, dlaczego
> > indeks klastrowy miałby być lepszy w złączeniach niż zwykły.
> 
> No przecież sam przytoczyłeś:
> 
> "...Clustered Index swoją strukturą najbardziej przypomina książkę 
> telefoniczną z ułożonymi alfabetycznie wpisami. Indeks ten nie jest 
> odrębnym obiektem składowanym na dysku twardym. Jego podstawowym 
> zadaniem jest narzucanie tabelom, w jaki sposób mają zapisywać wiersze 
> na kolejnych stronach. Istotną informacją jest fakt, iż po utworzeniu 
> indeksu grupującego, struktura stron tabeli podlega reorganizacji wg 
> wskazań indeksu..."
> Więc łącząc jakąś tabelę z tą tabelą po takim indeksie, od razu 
> dostajemy też dane, zamiast najpierw dowiedzieć się, gdzie te dane są i 
> dopiero po nie sięgnąć.
Wybacz, ale nadal nie rozumiem, co ma wspólnego przytoczony przeze mnie
tekst z szybszymi złączeniami. Uporządkowanie danych pomaga wtedy, gdy
po odczycie rekordu o numerze (fizycznym) N, jest duże prawdopodobieństwo
odczytania rekordu o numerze N+1. W jakich złączeniach tak jest?



> >> Nie, nie o to chodzi. Szukając klucza o wartości 100, w przypadku
> >> indeksu klastrowego przeszukiwana jest de facto tabela, tylko że
> >> wiadomo, iż ona "narasta" czyli trzeba przejść przez max. 100 wierszy.
> > To zależy od implementacji indeksu. Nie mam bladego pojęcia, jakie
> > są implementacje w popularnych bazach. W przypadku wyszukiwania
> > binarnego, maksymalna ilość wierszy, które trzeba poddać analizie,
> > zależy od ilości wszystkich rekordów w tabeli, a nie od wartości klucza.
> 
> Ale tu jest mowa o konkretnym indeksie _klastrowym_ i to w kontekście 
> MSSQL-a (ten cytat, który przytaczałeś dotyczy właśnie jego).
Nie rozumiem. Dlaczego MSSQL miałby przeglądać maksymalnie 100 rekordów
gdy id jest równe 100, w przypadku clustered? Sorry, ale nic kompletnie
nie kumam.

> 
> >> To nigdy nie jest wyliczana pozycja m.in. z tego powodu, który podałeś,
> >> ale także dlatego, że masz pola (kolumny) o dynamicznej wielkości (np.
> >> varchar), co pozwala upakować na stronie danych więcej tychże danych
> > Tak, to dodatkowy powód, ale tylko w pewnych implementacjach. Pole
> > może mieć stałą dlugość
> 
> Jeśli ma _stałą_ długość to nie jest varcharem - na tym polega 
> właściwość varchara, że nie zajmuje z góry ustalonego miejsca.
varchar może mieć dowolną długość, ale implementacja varchara może
być taka, że pole ma stałą długość. Po prostu string może być w
innym pliku, a w varchar może być odnośnik do niego.



> > Tak czy inaczej, rozmowa na ten temat chyba nic istotnego dla
> > programisty-użytkownika baz danych nie wnosi?
> 
> Zależy jakie masz oczekiwania wobec pisanego oprogramowania. Jeśli 
> wydajność nie jest tu kluczowa, to można sobie tym głowy nie zawracać. Z 
> drugiej strony, jeśli od razu projektujesz bazę wykorzystując taką 
> wiedzę, to potem nie będziesz musiał jej reorganizować.
Właśnie nie jestem przekonany czy jakakolwiek wiedza wystarczy do 
zapewnienia właściwej wydajności. Co na pewno warto zrobić? 
1) warto założyć indeksy 
2) warto niektóre zapytania przeanalizować
3) warto usunąć testy poprawności danych - wiadomo kosztem jakiego ryzyka
4) warto kupić sobie kontroler z bateryjnym podtrzymywaniem bufora zapisu
5) warto kupić dużo ram na bufor odczytu
6) warto kupić macierz ssd

A jak to nadal nie pomaga, to co Ci da informacja, ze varchar jest tak
czy inaczej zaimplementowany?


> > Mam zasadnicze pytanie dla dalszej rozmowy, czy warto tak szczegółową
> > wiedzę posiadać, czy lepiej traktować indeks, pole, tabelę, klucz, jako
> > (prawie) czarne skrzynki?
> 
> Odpowiedź jest taka sama jak poprzednia.
Moim zdaniem poprzednia odpowiedź nie ma praktycznego sensu. Drobiazgami
raczej nie podniesiesz istotnie wydajności bazy.


> >> Tu od razu zastrzegam, że piszę z pamięci, a od pewnego czasu nie siedzę
> >> zbyt intensywnie w bazach danych, więc mogło mi się już coś zatrzeć w
> >> pamięci. Co z kolei jest widomym powodem, że pora sobie trochę te
> >> wiadomości odświeżyć, więc być może wrzucę coś na bloga w tym temacie
> >> (gdybyż jeszcze ten czas).
> > Właśnie, gdy traktujemy bazę jako zestaw czarnych skrzynek, to czasu
> > mamy więcej.
> 
> Zależy który czas jest dla nas cenniejszy: nasz czy wszystkich 
> użytkowników naszego - być może zbyt wolnego - oprogramowania.
Tak, ale ile czasu użytkowników zaoszczędzą te duperele, w porównaniu z
oszczędnością jaką może dać powyższe 6 punktów? Wyciśniesz chociaż 5%
dzięki temu?


> 
> >> Zapewne w większości przypadków nie będzie to szczególnie kosztowne. A
> >> po to mamy tuning bazy danych, aby kiedy już koszt stanie się uciążliwy,
> >> po prostu ten tuning przeprowadzić.
> > Mogę poprosić o jakiś przykład, gdy to będzie bardzo kosztowne?
> 
> Int64 w stosunku do Int32, jeżeli zakres wartości nie ma szans sięgnąć 
> max tego drugiego, jest marnowaniem pamięci potrzebnej na przetwarzanie 
> złączeń. Dla Int32 da się załadować więcej tych wartości do cache niż 
> przy Int64.
Ale rozmawialiśmy int64 vs kod paskowy, a nie int64 vs int32. A co do
int32, to dzisiejsze kompy są szybkie, int32 naprawdę łatwo wyczerpać.


> > Nie wiem co to jest indeks integralny z danymi.
> 
> To jest właśnie indeks klastrowy - dane w tabeli są układane w 
> kolejności odpowiadającej regule indeksu (zgodnie z zacytowanym tekstem).
Rozumiem, że taka jest Twoja definicja, a w bazach danych może być
różnie.

> >> są przechowywane na stronach. Bywa (znów piszę z pamięci, ale
> >> chyba tak właśnie to działa), że zamiast relokować wiersze lepiej jest
> >> zostawić część na obecnej stronie, a te wstawiane wrzucić na nową i
> >> umieścić ją tuż za tamtą w logicznym łańcuchu stron.
> > Zależy dlaczego lepiej. Dla przeglądania sekwencyjnego gorzej, ponieważ
> > trzeba więcej danych przejrzeć. Dla wyszukiwania losowego chyba lepiej,
> > bo wystarczy jedną stronę wycztać. Dla wstawiania może być lepiej,
> > ale pod warunkiem, że zostawi się dużo wolnego miejsca.
> 
> Wiesz, projektanci baz wybrali nie bez powodu takie "poszatkowane" 
> rozwiązanie. Zapewne statystycznie jest ono najlepsze.
Zapewne. Rzadko kto ma bazę, która jest modyfikowana raz na miliardy
odczytów.



> >> Układ fizyczny tych
> >> stron będzie inny niż logiczny, więc mogą być od siebie oddalone w
> >> rzeczywistym pliku bazy o spory odstęp. Więc jest defragmentacja.
> > Ja chyba w ogóle nie rozumiem jak używasz określenia indeks :)
> > Z tego co piszesz, to po prostu kolejne ( w sensie sortowania ) dane nie
> > są pod kolejnymi adresami (w sensie sekwencyjnego odczytu).
> 
> Nie mam tyle czasu, aby to dogłębnie wytłumaczyć, a rzecz sprowadza się 
> do sposobu reprezentowania danych w samym pliku bazy. Tutaj odsyłam do 
> pozycji "Microsoft SQL Server 2008 od środka: Zapytania w języku T-SQL" 
> (przedostatnia pozycja działu Literatura na moim blogu). Z tym, że nie 
> wiem czy taka wiedza jest Ci potrzebna, jeżeli używasz Posgresa.
Mam książkę postgres wysokowydajny. Przeczytałem tylko początkowe
rozdziały. Raczej piszą o detalach (jak tuning algorytmu windy, czy
dobór systemu pliku) albo o sprawach oczywistych (jak przydział
pamięci na bufor plików w systemie albo w bazie - żeby nie dublować). 
Nie mam czasu aby doczytać tę pozycję do końca.


> >> Otóż strony pozostają niepełne właśnie ze względu na to, że może zajść
> >> potrzeba dodania pomiędzy znajdujące się na nich wiersze tego, który
> >> zgodnie z porządkiem powinien być tam umieszczony. I wówczas gdy strona
> >> nie jest w całości zapełniona, można taki wiersz dorzucić w owo puste
> >> miejsce (lub relokować w ramach strony istniejące tam wiersze, by
> >> wstawić ów nowy pomiędzy nie). SQL Serwer ma zdefiniowane jak tą pustą
> >> przestrzenią zarządzać, więc czasem dokłada do niej wiersze, a czasem z
> >> tego rezygnuje, jeśli z oszacowań wychodzi mu, że lepiej wstawić
> >> pomiędzy strony kolejną, a tamto puste miejsce pozostawić na przyszłe
> >> potrzeby.
> > To pewnie jest dobry kompromis pomiędzy wydajnym odczytem sekwencyjnym, a
> > wydajnymi modyfikacjami. Czy postgres też ma coś takiego?
> 
> Nie wiem, nie znam tej bazy, musiałbyś sprawdzić, wydaje mi się, że to 
> baza w której tabele są w plikach, więc tutaj stronicowanie tabeli może 
> być inaczej zrealizowane (może nie opłaca się jej stronicować?)
Też nie wiem, dla mnie to raczej czarne skrzynki. Gdy czasami próbuję
coś zoptymalizować, to mam bardzo dziwne zachowania. Np. 60 zapytań
trwa w w granicach 1.5-2 sekundy, a zapytanie 61 trwa 120 sekund. 
Zapytania są takie same, różnią się tylko offsetem po którym leżą
dane. Rozumiem, że z wydłużeniem offsetu rośnie czas, ale nagły skok z
2 sekund do 120? Nawet nie wiem jak zabrać się za optymalizację
tego, ani co wpisać w google.

Pozdrawiam

W dniu sobota, 21 lutego 2015 20:22:19 UTC+1 użytkownik M.M. napisał:

> Gdy czasami próbuję
> coś zoptymalizować, to mam bardzo dziwne zachowania. Np. 60 zapytań
> trwa w w granicach 1.5-2 sekundy, a zapytanie 61 trwa 120 sekund. 
> Zapytania są takie same, różnią się tylko offsetem po którym leżą
> dane. Rozumiem, że z wydłużeniem offsetu rośnie czas, ale nagły skok z
> 2 sekund do 120? Nawet nie wiem jak zabrać się za optymalizację
> tego, ani co wpisać w google.
> 

auto_explain ?
http://www.postgresql.org/docs/current/static/auto-explain.html

W dniu 2015-02-12 o 20:04, PaSkol pisze:
> W dniu 2015-02-12 o 10:34, nkab@toya.net.pl pisze:
>> Nie, id to sztuczny numer rekordu a indeks w pliku indeksowym
>> to fizyczny adres na dysku. Dyskowy system operacyjny (DOS) wie,
>> którą głowicę czytającą dysk uruchomić, na którym krążku magnetycznym,
>> na który sektor się ma ustawić głowica...
>
> Na dysku? Już nawet w DOS-ie w pewnym momencie przestało to być prawdą, bo
> dyski fizycznie były inaczej skonstruowane, a BIOS dostawał ich wirtualną
> adresację (bo nie był w stanie zaadresować takiej ilości sektorów). Więc
> choćby z tego powodu to nieprawda.
Bzdura. Jeśli nie, czekam na dowód. Dyski rosły, a DOS miał ograniczenia, 
powodem była krótkowzroczność, nie niemożność.
>
> A jeśli już mówić o adresie, to nawet w DBF był to numer rekordu (lub
> przesunięcie w ramach danej tabeli - pliku DBF), a nie adres na dysku.
Swiat się zmienia, adres łatwo zmienić. Piszecie sobie coś... Czy to będzie 
miało odbicie w realnym świecie? To są dywagacje, udawanie czegoś czego nie 
widzicie. W innym wypadku nie mielibyście czasu na to, a weekend i tak by 
wam tego spokoju nie zapewnił.

>> Indeksy są dla zawodowców amatorom wystarczy order by.
Delikatny będę: Pojebało Cię?
>
> Doznałem olśnienia - już wiem czemu jest tylu amatorów na świecie :>.
>
>> Programista baz danych nie używa id, dla zawodowca id nie istnieje.
>> Id jest dla administratora bazy danych, daje informacje, że były
>> usuwane rekordy.
>
> Czy zawodowiec to taki gość, który doznaje zawodu, bo (jak rozpatruję sprawę
> niżej) ktoś mu usunął rekord/wiersz/krotkę, a on biedny nie wie co teraz z
> tym zrobić?
>
>> id nick
>> --------------
>> 1  R.E.M.E.K
>> 2  nkab
>> 3  MM
>> 4  MAREK
>>
>> i teraz ktoś bez twojej wiedzy usunął nkab, co zrobisz
>> gdy w drugiej tabeli masz posty do tych ników połączonych
>> poprzez id, no co zrobisz?
>
> Widzisz, takie rzeczy to były możliwe tylko w DBF i podobnych systemach
> (gdzie pojęcie "system" jest nadużyciem w ich wypadku) obsługi baz danych.
> Obecnie RDBMS (Relationa DataBase Managament System - czyli po naszemu
> system zarządzania relacyjną bazą danych), jeśli tylko zdefiniuje mu się
> więzy integralności danych nie dopuści do takiej sytuacji. Owe więzy
> integralności (chyba od naszej ostatniej dyskusji nie doczytałeś nic na ten
> temat) polegają w uproszczeniu na tym, że RDBMS posiada informację, że
> rekordy z Twojej przykładowej tabeli są powiązane z inną tabelą i można je
> usunąć jedynie wspólnie (jeden z przypadków) albo tzw. nadrzędny rekord
> można usunąć jedynie, kiedy wszystkie powiązane z nim rekordy w dodatkowej
> tabeli zostaną usunięte wcześniej (oczywiście nie dotyczy to tylko usuwania
> i nie jest to jedyny sposób zapewnienia integralności, ale nie chcę
> komplikować).
>
>  > Napisz koledze M.M. o indeksach tak aby on to
>  > zrozumiał, żeby się połapał, że jak da:
>  >
>  > SELECT nick from t1       (bez indeksów) to da mu:
>  >
>  > R.E.M.E.K
>  > nkab
>  > MM
>  > MAREK
>  >
>  > a po dodaniu indeksu dla pola nick
>  >
>  > SELECT nick from t1      (z indeksami) da mu:
>  >
>  > MAREK
>  > nkab
>  > MM
>  > R.E.M.E.K
>  >
>  > i nie ma tu ORDER BY a jednak są w kolejności
>  > alfabetycznej
>
> To ja ostrożnie zapytam - w jakim RDBMS? Nie znam PostgreSQL, ale w dość
> dobrze znanym mi MSSQL (lub SQL Server - jak kto woli) dodanie poleceniem
> *insert* zgodnie z powyższą, przypadkową kolejnością może ale nie musi dla
> *select* zwrócić w kolejności dodawania. Bo ta kolejność jest z definicji
> przypadkowa, co obejmuje też przypadek, że będzie akurat kolejnością dodawania.
>
> Co więcej - w MSSQL nie trzeba podawać w zapytaniu indeksów, bo jeśli takowe
> są założone dla tabeli, to optymalizator silnika serwera SQL je wykorzysta
> (o ile będzie to opłacalne). Co więcej - potrafi też sobie poradzić z
> wykorzystaniem indeksu złożonego (czyli p1 + p2) dla zaprezentowania w
> kolejności zgodnej z jednym z pól wchodzących w jego skład. Pomijam już
> fakt, że w jego przypadku indeksy tylko w jednym przypadku wskazują na
> położenie wiersza, a w pozostałych, gdy jest indeks klastrowy na tabeli,
> wskazują na wartość tego indeksu.
>
> Indeksy to już od dłuższego czasu nie pliki (bo baza danych jest plikiem).
> To po prostu zbiory danych (danymi są indeksy), zazwyczaj (zależy do RDBMS)
> niezajmujące spójnego obszaru.
>

Nie ma sensu. Zostaw - jeśli ktoś nie umie dodać 2 i dwa to niech będzie 
order by i filtry.
Inna rzecz: ktoś kiedyś mnie zapytał -"a jak to robi google" - o 
wyszukiwanie chodziło. Zabili mnie tym pytaniem :) Odpowiedziałem: mają 
kasę, której wy nie macie - było po rozmowie.

-- 
Artur
0 weeks 0 days 2 hours 54 minutes 20 seconds and 92 milliseconds.
"pl.comp.bazy-danych"

W dniu 2015-02-22 o 08:18, artiun pisze:
>> Na dysku? Już nawet w DOS-ie w pewnym momencie przestało to być
>> prawdą, bo
>> dyski fizycznie były inaczej skonstruowane, a BIOS dostawał ich wirtualną
>> adresację (bo nie był w stanie zaadresować takiej ilości sektorów). Więc
>> choćby z tego powodu to nieprawda.
> Bzdura. Jeśli nie, czekam na dowód. Dyski rosły, a DOS miał
> ograniczenia, powodem była krótkowzroczność, nie niemożność.

http://en.wikipedia.org/wiki/Cylinder-head-sector
http://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html

W pewnym momencie dyski nadal posiadały 4 głowice odczytujące (dwa 
talerze), a w BIOS było wpisane że jest ich 16. I system operacyjny 
przez przerwanie BIOS (13h) chcąc się dostać do konkretnego miejsca na 
dysku adresował je przez jedną z 16 głowic. W tym drugim linku masz 
pierwszą pozycję, która tłumaczy, jaki był maksymalny rozmiar dysku, 
który potrafił zaadresować taki BIOS, dlatego jeśli rozmiar nie dał się 
zaadresować na 4 głowicach, trzeba było "kombinować" właśnie poprzez 
"udawanie", że głowic jest więcej niż w rzeczywistości.

>> A jeśli już mówić o adresie, to nawet w DBF był to numer rekordu (lub
>> przesunięcie w ramach danej tabeli - pliku DBF), a nie adres na dysku.
> Swiat się zmienia, adres łatwo zmienić. Piszecie sobie coś... Czy to
> będzie miało odbicie w realnym świecie? To są dywagacje, udawanie czegoś
> czego nie widzicie. W innym wypadku nie mielibyście czasu na to, a
> weekend i tak by wam tego spokoju nie zapewnił.
>
>>> Indeksy są dla zawodowców amatorom wystarczy order by.
> Delikatny będę: Pojebało Cię?

Mnie? Bo jeśli odpowiadasz nkabowi, to kiepskie sobie wybrałeś miejsce - 
przecież nie będzie czytał odpowiedzi na mój post, aby się zorientować, 
że ktoś tu z nim uderza w polemikę.


-- 
PaSkol (paskol.robi.to)

W dniu 2015-02-21 o 20:22, M.M. pisze:
> Wybacz, ale nadal nie rozumiem, co ma wspólnego przytoczony przeze mnie
> tekst z szybszymi złączeniami. Uporządkowanie danych pomaga wtedy, gdy
> po odczycie rekordu o numerze (fizycznym) N, jest duże prawdopodobieństwo
> odczytania rekordu o numerze N+1. W jakich złączeniach tak jest?

Dla mnie szybkość złączenia, to szybkość z jaką otrzymam dane, które to 
złączenie mi zapewnia. A wyjaśniłem wszak dlaczego dane w przypadku 
indeksu klastrowego uzyskuje się szybciej.

>> Ale tu jest mowa o konkretnym indeksie _klastrowym_ i to w kontekście
>> MSSQL-a (ten cytat, który przytaczałeś dotyczy właśnie jego).
> Nie rozumiem. Dlaczego MSSQL miałby przeglądać maksymalnie 100 rekordów
> gdy id jest równe 100, w przypadku clustered? Sorry, ale nic kompletnie
> nie kumam.

Ustawia się na początku indeksu (pomińmy rozważania na poziomie 
b-drzewa, traktujmy indeks logicznie). Pobiera pierwsza wartość i 
porównuje z oczekiwaną. Jeśli jest to wartość 1 to musi przejść przez 
kolejne 100 rekordów (bo dane są ułożone w kolejności), aby otrzymać 
ten, którego Id = 100. Prościej już nie mogę tego wytłumaczyć. W MSSQL 
silnik bazy danych nie wylicza sobie bezpośrednio pozycji rekordu, on 
potrafi przeskakiwać kolejne rekordy (bo wie jaki jest rozmiar każdego z 
nich z osobna), aby dotrzeć do oczekiwanej wartości. Nie wylicza też z 
powodów, o których już sam pisałeś - mogą być dziury w wartościach 
klucza. Nie ma wyjścia - trzeba przeszukać całość, ale można tylko 
wybrane fragmenty.

Pod adresem, z którego przytoczono fragment o indeksach klastrowych jest 
podany przykład takiej struktury w świecie rzeczywistym: to książka 
telefoniczna, w której abonenci są ułożeni alfabetycznie. Odszukanie 
konkretnego nazwiska polega zatem na przejrzeniu kilku stron poczynając 
od tej, na której zaczynają się nazwiska na daną literę.

>> Jeśli ma _stałą_ długość to nie jest varcharem - na tym polega
>> właściwość varchara, że nie zajmuje z góry ustalonego miejsca.
> varchar może mieć dowolną długość, ale implementacja varchara może
> być taka, że pole ma stałą długość. Po prostu string może być w
> innym pliku, a w varchar może być odnośnik do niego.

No to ja RDBMS, który w taki sposób (i tak rezerwując określoną długość) 
implementuje varchar, bym nie używał. A to że varchar może być w 
oddzielnym pliku niczego nie zmienia. W tym oddzielnym pliku (w MSSQL 
oddzielnym obszarze danych - LOB) on także będzie mieć tylko taką 
długość jak trzeba.

> Właśnie nie jestem przekonany czy jakakolwiek wiedza wystarczy do
> zapewnienia właściwej wydajności. Co na pewno warto zrobić?

Oczywiście, że wystarczy. Świadczy o tym choćby fakt, że są ludzie 
całkiem dobrze żyjący ze świadczenia usług optymalizacji (strojenia) baz 
danych. Bo okazuje się, że niefrasobliwość programistów prowadzi w 
konsekwencji do eskalacji potrzeb sprzętowych.

> 1) warto założyć indeksy

Owszem ale nie we wszystkich przypadkach, a w dodatku ze względu na 
różność indeksów czasem warto założyć taki konkretny (np. zawierający 
dodatkowo daną, która jest wyszukiwana, aby nie trzeba było po nią 
sięgać do tabeli).

> 2) warto niektóre zapytania przeanalizować

No i? Jak potem bez odpowiedniej wiedzy dojdziesz, dlaczego działają raz 
wolno a raz szybko (jak pytasz poniżej)?

> 3) warto usunąć testy poprawności danych - wiadomo kosztem jakiego ryzyka

Owszem można nie testować danych na poziomie bazy (bo można, a czasami 
wręcz lepiej zrobić to wcześniej).

> 4) warto kupić sobie kontroler z bateryjnym podtrzymywaniem bufora zapisu

A to akurat z wydajnością niewiele ma wspólnego

> 5) warto kupić dużo ram na bufor odczytu
> 6) warto kupić macierz ssd

Jak pisałem - w końcu może się okazać, że to za mało. Poza tym - chmura.

> A jak to nadal nie pomaga, to co Ci da informacja, ze varchar jest tak
> czy inaczej zaimplementowany?

A po co w ogóle wprowadzono varchar? Gdyby nie było potrzebne, to by go 
po prostu nie było. Okazało się jednak, że jest wręcz nieodzowne. Zatem 
varchar, który varcharem nie jest to jak mieć randkę z transwestytą, 
choć zamierzaliśmy z kobietą.

>>> Mam zasadnicze pytanie dla dalszej rozmowy, czy warto tak szczegółową
>>> wiedzę posiadać, czy lepiej traktować indeks, pole, tabelę, klucz, jako
>>> (prawie) czarne skrzynki?
>>
>> Odpowiedź jest taka sama jak poprzednia.
> Moim zdaniem poprzednia odpowiedź nie ma praktycznego sensu. Drobiazgami
> raczej nie podniesiesz istotnie wydajności bazy.

Nie mam na myśli podniesienie, mam na myśli obniżenie. Po prostu już na 
wstępie masz bazę, która wymaga większych zasobów niż to konieczne.

>> Zależy który czas jest dla nas cenniejszy: nasz czy wszystkich
>> użytkowników naszego - być może zbyt wolnego - oprogramowania.
> Tak, ale ile czasu użytkowników zaoszczędzą te duperele, w porównaniu z
> oszczędnością jaką może dać powyższe 6 punktów? Wyciśniesz chociaż 5%
> dzięki temu?

Jak napisałem - chodzi o to, aby nie doprowadzić do całkowicie 
niewydajnej bazy danych (gdzie np. 50% obszaru zajmują puste miejsca, a 
indeksy są dublowane).

>>>> Zapewne w większości przypadków nie będzie to szczególnie kosztowne. A
>>>> po to mamy tuning bazy danych, aby kiedy już koszt stanie się uciążliwy,
>>>> po prostu ten tuning przeprowadzić.
>>> Mogę poprosić o jakiś przykład, gdy to będzie bardzo kosztowne?
>>
>> Int64 w stosunku do Int32, jeżeli zakres wartości nie ma szans sięgnąć
>> max tego drugiego, jest marnowaniem pamięci potrzebnej na przetwarzanie
>> złączeń. Dla Int32 da się załadować więcej tych wartości do cache niż
>> przy Int64.
> Ale rozmawialiśmy int64 vs kod paskowy, a nie int64 vs int32. A co do
> int32, to dzisiejsze kompy są szybkie, int32 naprawdę łatwo wyczerpać.

Nie odebrałem tego w ten sposób. Czyli chciałbym przechowywać kod 
paskowy na Int64? A co z zerami wiodącymi w takim kodzie. Kod paskowy 
przechowuje się jako tekst - niestety. Stąd zresztą podałem go w 
przykładzie. Nie bardzo też widzę związek z szybkością komputerów i 
wyczerpaniem Int32. To przecież zależy od rodzaju danych (ich zakresu).

>
>>> Nie wiem co to jest indeks integralny z danymi.
>>
>> To jest właśnie indeks klastrowy - dane w tabeli są układane w
>> kolejności odpowiadającej regule indeksu (zgodnie z zacytowanym tekstem).
> Rozumiem, że taka jest Twoja definicja, a w bazach danych może być
> różnie.

Nie - taka jest definicja indeksu klastrowego. Zajrzyj pod link, który 
sam odnalazłeś. Skojarz go z książką telefoniczną.


-- 
PaSkol (paskol.robi.to)

W dniu 2015-02-22 o 09:15, PaSkol pisze:
> W dniu 2015-02-22 o 08:18, artiun pisze:
>>> Na dysku? Już nawet w DOS-ie w pewnym momencie przestało to być
>>> prawdą, bo
>>> dyski fizycznie były inaczej skonstruowane, a BIOS dostawał ich wirtualną
>>> adresację (bo nie był w stanie zaadresować takiej ilości sektorów). Więc
>>> choćby z tego powodu to nieprawda.
>> Bzdura. Jeśli nie, czekam na dowód. Dyski rosły, a DOS miał
>> ograniczenia, powodem była krótkowzroczność, nie niemożność.
>
> http://en.wikipedia.org/wiki/Cylinder-head-sector
> http://www.tldp.org/HOWTO/Large-Disk-HOWTO-4.html
>
> W pewnym momencie dyski nadal posiadały 4 głowice odczytujące (dwa talerze),
> a w BIOS było wpisane że jest ich 16. I system operacyjny przez przerwanie
> BIOS (13h) chcąc się dostać do konkretnego miejsca na dysku adresował je
> przez jedną z 16 głowic. W tym drugim linku masz pierwszą pozycję, która
> tłumaczy, jaki był maksymalny rozmiar dysku, który potrafił zaadresować taki
> BIOS, dlatego jeśli rozmiar nie dał się zaadresować na 4 głowicach, trzeba
> było "kombinować" właśnie poprzez "udawanie", że głowic jest więcej niż w
> rzeczywistości.
>
Jeśli tak, o kłócił się nie będę. Mam co prawda kilka rozebranych na półce. 
Chyba jest nawet Maxtor 512MB. Nie miał 16 talerzy (inne też). Zresztą 
wszystkie miały po 2 głowice (mogę, bo mam dołączyć zdjęcia :) ). Jak to 
jest robione sprzętowo nie obchodziło mnie. Stare dyski miały zworki - by 
puszczać je powyżej 2GB (mogę się mylić jeśli idzie o GB).
Tak czy inaczej, zaczynając studia w Opolu miałem okazję zobaczyć Odrę, 
kajdanki i aluminiowe pulpity. Na uczelni dostępne były wtedy 2xAT i 6xXT. 
Jak kończyłem to już wszystko stało na 386 i Pentium. A RAm był liczony w MB 
:) Z kumplem (par pokoi dalej) graliśmy w Doom'a - do czasu, "Opole - 
piastonalia", jakieć coś powiesiło sie na kablu/przewodzie (urwał). Śmisznie 
było (on kolorowy monitor, ja odcienie szarości, dostał czasem w plecy :))
>>> A jeśli już mówić o adresie, to nawet w DBF był to numer rekordu (lub
>>> przesunięcie w ramach danej tabeli - pliku DBF), a nie adres na dysku.
>> Swiat się zmienia, adres łatwo zmienić. Piszecie sobie coś... Czy to
>> będzie miało odbicie w realnym świecie? To są dywagacje, udawanie czegoś
>> czego nie widzicie. W innym wypadku nie mielibyście czasu na to, a
>> weekend i tak by wam tego spokoju nie zapewnił.
>>
>>>> Indeksy są dla zawodowców amatorom wystarczy order by.
>> Delikatny będę: Pojebało Cię?
>
> Mnie? Bo jeśli odpowiadasz nkabowi, to kiepskie sobie wybrałeś miejsce -
> przecież nie będzie czytał odpowiedzi na mój post, aby się zorientować, że
> ktoś tu z nim uderza w polemikę.
>
To przepraszam. Jeśli rozmawiamy o różnicach między ORDER BY a indeksem to 
nie ma znaczenia z pkt usera, czy to będzie osobny plik (jak np w dbf), czy 
zawarty w bazie jak np (sqlite - tylko przykład bo firebird tak roboi). Z 
punktu widzenia - nawet dla admina bazy - nie ma to znaczenia jak dana baza 
jest skonstruowana. :) o swoich animozjach do MS SQL'a nie będę pisał, co 
rusz musiałem go ogarniać.


-- 
Artur
0 weeks 0 days 6 hours 33 minutes 46 seconds and 925 milliseconds.
"pl.comp.bazy-danych"

On Sunday, February 22, 2015 at 10:10:11 AM UTC+1, PaSkol wrote:
> W dniu 2015-02-21 o 20:22, M.M. pisze:
> > Wybacz, ale nadal nie rozumiem, co ma wspólnego przytoczony przeze mnie
> > tekst z szybszymi złączeniami. Uporządkowanie danych pomaga wtedy, gdy
> > po odczycie rekordu o numerze (fizycznym) N, jest duże prawdopodobieństwo
> > odczytania rekordu o numerze N+1. W jakich złączeniach tak jest?
> 
> Dla mnie szybkość złączenia, to szybkość z jaką otrzymam dane, które to 
> złączenie mi zapewnia. A wyjaśniłem wszak dlaczego dane w przypadku 
> indeksu klastrowego uzyskuje się szybciej.
Myślę że się mylisz, myślę że jest podobnie. Zakładam że autorzy silników 
baz danych nie dali dupy. Mamy tabelę która ma powiedzmy 10^9 rekordów.
Chcemy rekord:

select * from tabela where pole=coś.

Stosujemy b-tree do ineksowania. Root mamy w RAM - więc koszt odpada.
Breanchfactor przy stronie 4kb jaki może być? Może być 500? Mamy
500^x = 10^9. Przy tysiącu byłoby x=3. Czyli przy 500 spodziewamy się 
jakiś 4-5 dostępów do dysku.

Stosujemy clustered. Bierzemy:

start = select cos from tabela order by cos limit 1 
i
end = select cos from tabela order by desc cos limit 1 

Ze start i end liczymy prostą ax+b. Szykamy punktu podziału...
Mamy złożoność \Theta(\log \log n), 
dla 10^9 wychodzi 4,9019458471

Widzisz pewne podobieństwo?

A jeśli w danych nie ma rozkładu jednostajnego to co? To dobra
baza danych powinna się zorientować, ze trzeba stosować zwykłe
wyszukiwanie binarne. Więc wychodzi
= LOG(10^9;2) = 29,897352854

Czyli wolniej. Więc baza powinna założyć zwykłe b-tree pomimo 
clustered.


Chętnie dowiem się co pomylilem w powyższym rozumowaniu.


> >> Ale tu jest mowa o konkretnym indeksie _klastrowym_ i to w kontekście
> >> MSSQL-a (ten cytat, który przytaczałeś dotyczy właśnie jego).
> > Nie rozumiem. Dlaczego MSSQL miałby przeglądać maksymalnie 100 rekordów
> > gdy id jest równe 100, w przypadku clustered? Sorry, ale nic kompletnie
> > nie kumam.
> 
> Ustawia się na początku indeksu (pomińmy rozważania na poziomie 
> b-drzewa, traktujmy indeks logicznie). 
Nie wiem na czym polega traktowanie indesku logicznie.

> Pobiera pierwsza wartość i 
> porównuje z oczekiwaną. Jeśli jest to wartość 1 to musi przejść przez 
> kolejne 100 rekordów (bo dane są ułożone w kolejności), 
Jeśli ma indeks, to nie musi. Często trafia w rekord z tą stówą już
po 3-5 'dostępach do dysku'. Piszę w cudzyslowie, bo może być
wszystko w RAM.

> aby otrzymać 
> ten, którego Id = 100. Prościej już nie mogę tego wytłumaczyć. 
Ale nie wiem po co mi to tłumaczysz, jeśli można to zrobić
szybciej - z indeksem.



> W MSSQL 
> silnik bazy danych nie wylicza sobie bezpośrednio pozycji rekordu, on 
> potrafi przeskakiwać kolejne rekordy (bo wie jaki jest rozmiar każdego z 
> nich z osobna), aby dotrzeć do oczekiwanej wartości. Nie wylicza też z 
> powodów, o których już sam pisałeś - mogą być dziury w wartościach 
> klucza. Nie ma wyjścia - trzeba przeszukać całość, ale można tylko 
> wybrane fragmenty.
Chyba piszesz o dwoch rzeczach, a ja nie chwytam kiedy o której. Raz
piszesz że przeskakuje, drugi raz że musi szykać calość. Sorrki, nie
kumam. 



> Pod adresem, z którego przytoczono fragment o indeksach klastrowych jest 
> podany przykład takiej struktury w świecie rzeczywistym: to książka 
> telefoniczna, w której abonenci są ułożeni alfabetycznie. Odszukanie 
> konkretnego nazwiska polega zatem na przejrzeniu kilku stron poczynając 
> od tej, na której zaczynają się nazwiska na daną literę.
Ale można pszeszukiwać inaczej, zwłaszcza gdy szuka algorytm na kompie, a 
nie czlowiek w książce.


> 
> >> Jeśli ma _stałą_ długość to nie jest varcharem - na tym polega
> >> właściwość varchara, że nie zajmuje z góry ustalonego miejsca.
> > varchar może mieć dowolną długość, ale implementacja varchara może
> > być taka, że pole ma stałą długość. Po prostu string może być w
> > innym pliku, a w varchar może być odnośnik do niego.
> 
> No to ja RDBMS, który w taki sposób (i tak rezerwując określoną długość) 
> implementuje varchar, bym nie używał. A to że varchar może być w 
> oddzielnym pliku niczego nie zmienia. W tym oddzielnym pliku (w MSSQL 
> oddzielnym obszarze danych - LOB) on także będzie mieć tylko taką 
> długość jak trzeba.
Ja w C++ takie sztuczki używałem. Miałem pliki o stałej długości
rekordu. W rekordzie czasami używalem wskaźnika do danych w innym
pliku. Biło to wydajnościowo na głowę bazy danych, ale zabierało
masę czasu przy projektowaniu i implementacji. Teraz czasy się zmieniły,
można kupić tani komputer który ma 1TB RAM i dwa procesory 8 rdzeniowe.


> > Właśnie nie jestem przekonany czy jakakolwiek wiedza wystarczy do
> > zapewnienia właściwej wydajności. Co na pewno warto zrobić?
> 
> Oczywiście, że wystarczy. Świadczy o tym choćby fakt, że są ludzie 
> całkiem dobrze żyjący ze świadczenia usług optymalizacji (strojenia) baz 
> danych. Bo okazuje się, że niefrasobliwość programistów prowadzi w 
> konsekwencji do eskalacji potrzeb sprzętowych.
Mógłby odpowiedzieć, że są ludzie calkiem dobrze żyjący ze sprzedaży
systemów na grę w lotto. Ale nie odpowiem tak, odpowiem, że zaciekawiasz
mnie. Ja nie jestem specem od baz danych. Nagle moja baza danych
działa zbyt wolno. Więc po kolei:
1) zakładam indeksy
2) dokupuję ram i cała baza mieści się w buforze
3) dokupuję kontroler z bateryjnym podtrzymywaniem bufora zapisu
4) wyłączam więzy integralności
5) lekko denormalizuję bazę
6) robię kilka przebórek niektórych zapytań sql
7) kupuję dysk ssd na pci i tam trzymam krytyczne dla wydajności tabele
8) robię replikację i powielam wszystko na kilka maszyn
Co więcej (i rzecz jasna taniej) zrobi osoba dobrze żyjąca ze strojenia 
baz danych?




> > 1) warto założyć indeksy
> 
> Owszem ale nie we wszystkich przypadkach, a w dodatku ze względu na 
> różność indeksów czasem warto założyć taki konkretny (np. zawierający 
> dodatkowo daną, która jest wyszukiwana, aby nie trzeba było po nią 
> sięgać do tabeli).
Czy móglbyś jakoś wykazać, ze to jest duża optymalizacja, a nie
uganianie się za pojedynczymi milisekundami?


> > 2) warto niektóre zapytania przeanalizować
> 
> No i? Jak potem bez odpowiedniej wiedzy dojdziesz, dlaczego działają raz 
> wolno a raz szybko (jak pytasz poniżej)?
Ja jak dojdę? Metodą intuicji, prób i błędów. Zwykle robię coś na 2-3 
sposoby i wybieram ten który najszybciej działa. Jeśli cała baza jest w
ram, jeśli zapytanie tylko odczytuje dane, to co ekspert zrobi
lepiej? Ma lepiej wypracowaną intuicję i sprawdzi jeszcze 2 sposoby?
Nie jestem do końca przekonany, możesz podać jakiś przykład dwóch rozwiązań?
Jedno rozwiązanie typowe dla przeciętnego programisty, a drugie od eksperta?


> > 3) warto usunąć testy poprawności danych - wiadomo kosztem jakiego ryzyka
> 
> Owszem można nie testować danych na poziomie bazy (bo można, a czasami 
> wręcz lepiej zrobić to wcześniej).
Jeśli testujesz klucze obce to i tak i tak musi być dostęp do danych. No
chyba że w programie masz kopię kluczy.


> > 4) warto kupić sobie kontroler z bateryjnym podtrzymywaniem bufora zapisu
> 
> A to akurat z wydajnością niewiele ma wspólnego
Jak dasz buforowany zapis bez podtrzymywania bateryjnego, to w wyniku
awarii zasilania co będzie?


> > 5) warto kupić dużo ram na bufor odczytu
> > 6) warto kupić macierz ssd
> 
> Jak pisałem - w końcu może się okazać, że to za mało. Poza tym - chmura.
Chmura jest cholernie droga, poza sytuacjami, gdy na krótką chwilę
potrzebujesz wiele sprzętu, a potem na długi okres prawie całkowicie 
go zwalniasz.


> > A jak to nadal nie pomaga, to co Ci da informacja, ze varchar jest tak
> > czy inaczej zaimplementowany?
> 
> A po co w ogóle wprowadzono varchar? Gdyby nie było potrzebne, to by go 
> po prostu nie było. Okazało się jednak, że jest wręcz nieodzowne. Zatem 
> varchar, który varcharem nie jest to jak mieć randkę z transwestytą, 
> choć zamierzaliśmy z kobietą.
Ale nie piszemy o przydatności w ogóle varchar, tylko o optymalizacji 
takich drobiazgów jak varchar. 


> >>> Mam zasadnicze pytanie dla dalszej rozmowy, czy warto tak szczegółową
> >>> wiedzę posiadać, czy lepiej traktować indeks, pole, tabelę, klucz, jako
> >>> (prawie) czarne skrzynki?
> >>
> >> Odpowiedź jest taka sama jak poprzednia.
> > Moim zdaniem poprzednia odpowiedź nie ma praktycznego sensu. Drobiazgami
> > raczej nie podniesiesz istotnie wydajności bazy.
> 
> Nie mam na myśli podniesienie, mam na myśli obniżenie. Po prostu już na 
> wstępie masz bazę, która wymaga większych zasobów niż to konieczne.
I z powodu varchar nie podniesiesz istotnie wydajności tamtymi 6 punktami?
Chciałbym to zobaczyć.



> >> Zależy który czas jest dla nas cenniejszy: nasz czy wszystkich
> >> użytkowników naszego - być może zbyt wolnego - oprogramowania.
> > Tak, ale ile czasu użytkowników zaoszczędzą te duperele, w porównaniu z
> > oszczędnością jaką może dać powyższe 6 punktów? Wyciśniesz chociaż 5%
> > dzięki temu?
> 
> Jak napisałem - chodzi o to, aby nie doprowadzić do całkowicie 
> niewydajnej bazy danych (gdzie np. 50% obszaru zajmują puste miejsca, a 
> indeksy są dublowane).
Nie wiem czy pustym obszarem możemy dziś się nadal martwić. Dziś w
kiosku można kupić komputer który ma 1TB RAM i 16 fizycznych rdzeni.
A dublowane indeksy, to raczej przedszkole, do tego eksperta chyba nie trzeba?


> >>>> Zapewne w większości przypadków nie będzie to szczególnie kosztowne. A
> >>>> po to mamy tuning bazy danych, aby kiedy już koszt stanie się uciążliwy,
> >>>> po prostu ten tuning przeprowadzić.
> >>> Mogę poprosić o jakiś przykład, gdy to będzie bardzo kosztowne?
> >>
> >> Int64 w stosunku do Int32, jeżeli zakres wartości nie ma szans sięgnąć
> >> max tego drugiego, jest marnowaniem pamięci potrzebnej na przetwarzanie
> >> złączeń. Dla Int32 da się załadować więcej tych wartości do cache niż
> >> przy Int64.
> > Ale rozmawialiśmy int64 vs kod paskowy, a nie int64 vs int32. A co do
> > int32, to dzisiejsze kompy są szybkie, int32 naprawdę łatwo wyczerpać.
> 
> Nie odebrałem tego w ten sposób. Czyli chciałbym przechowywać kod 
> paskowy na Int64? 
Rozmawialiśmy o indeksach naturalnycyh, jak pesel, kod paskowy, albo
nazwa systematyczna gatunku. Odpowiedziałem, że pomimo istnienia 
indeksów naturalnych, używam klucza własnego int64. Może robię
głupio, oczekiwałem krytyki w kierunku klucz narutalny vs sztuczny int64.


> A co z zerami wiodącymi w takim kodzie. Kod paskowy 
> przechowuje się jako tekst - niestety. Stąd zresztą podałem go w 
> przykładzie. 
Więc może rozwiązanie: 'zawsze klucz sztuczny na int32 lub int64' - 
jest jednak dobre?

> Nie bardzo też widzę związek z szybkością komputerów i 
> wyczerpaniem Int32. To przecież zależy od rodzaju danych (ich zakresu).
Na wolnych kompach trzeba dłużej liczyć, aby wyczerpać int32.


> >>> Nie wiem co to jest indeks integralny z danymi.
> >>
> >> To jest właśnie indeks klastrowy - dane w tabeli są układane w
> >> kolejności odpowiadającej regule indeksu (zgodnie z zacytowanym tekstem).
> > Rozumiem, że taka jest Twoja definicja, a w bazach danych może być
> > różnie.
> 
> Nie - taka jest definicja indeksu klastrowego. Zajrzyj pod link, który 
> sam odnalazłeś. Skojarz go z książką telefoniczną.
Ok.

Generalnie posdumowując całość, chciałbym się naocznie przekonać o tym 
co piszesz. Tak w teoretycznej rozmowie jakoś nie mogę uwierzyć.

Pozdrawiam

W dniu 2015-02-22 o 08:18, artiun pisze:
>>
>
> Nie ma sensu. Zostaw - jeśli ktoś nie umie dodać 2 i dwa to niech będzie
> order by i filtry.
Od tygodni to powtarzam :)

> Inna rzecz: ktoś kiedyś mnie zapytał -"a jak to robi google" - o
> wyszukiwanie chodziło. Zabili mnie tym pytaniem :)
Dlaczego?

Mam wrażenie, że podchodzisz do tematu zbyt technicznie. Innymi słowy - 
za dużo wiesz i za dużo widziałeś :)

Daj to do zrobienia komuś, kto nie wie jak to działa w google (nawet w 
przybliżeniu) i pewnie to zrobi.
Pewnie implementacja nie rzuci nikogo na kolana, ale będzie działać :)
A przecież o to właśnie klientowi chodzi, prawda? Ma działać i ma w 
dupie jak to jest zrobione.

> Odpowiedziałem: mają
> kasę, której wy nie macie - było po rozmowie.
Wyślij ich do mnie, zapewniam Cię że nie będzie po rozmowie ;-)
Ja podchodzę do tego w inny sposób; po pierwsze, nigdy nie mówić NIE (da 
się), bo wszystko jest kwestią czasu, czytaj kasy.

Poza tym zauważ (co prawda nie znam kontekstu, czyli co ta za system, 
jakie obciążenie ile i jakie dane, itd.), że zabawa z LIKE + 
CONVERT/CAST da radę w zadowalającym czasie dla typowych zestawów (kilka 
do kilkudziesięciu tyś rekordów) danych w dzisiejszym systemie ERP. I da 
się to zaprogramować uniwersalnie.

Sprawdziłem, zaimplementowałem i wdrożyłem - jest OK. Czasem wymagana 
jest preselekcja danych do wyszukiwania (aby odrzucić nieistotne 
rekordu, np. archiwalne), ale i tak jest lepiej niż standardowe 
formularze do wyszukiwania.

-- 
wloochacz

W dniu 2015-02-22 o 17:34, wloochacz pisze:
> W dniu 2015-02-22 o 08:18, artiun pisze:
>>>
>>
>> Nie ma sensu. Zostaw - jeśli ktoś nie umie dodać 2 i dwa to niech będzie
>> order by i filtry.
> Od tygodni to powtarzam :)
>
>> Inna rzecz: ktoś kiedyś mnie zapytał -"a jak to robi google" - o
>> wyszukiwanie chodziło. Zabili mnie tym pytaniem :)
> Dlaczego?
>
> Mam wrażenie, że podchodzisz do tematu zbyt technicznie. Innymi słowy - za
> dużo wiesz i za dużo widziałeś :)
>
> Daj to do zrobienia komuś, kto nie wie jak to działa w google (nawet w
> przybliżeniu) i pewnie to zrobi.
> Pewnie implementacja nie rzuci nikogo na kolana, ale będzie działać :)
> A przecież o to właśnie klientowi chodzi, prawda? Ma działać i ma w dupie
> jak to jest zrobione.
>
>> Odpowiedziałem: mają
>> kasę, której wy nie macie - było po rozmowie.
> Wyślij ich do mnie, zapewniam Cię że nie będzie po rozmowie ;-)
> Ja podchodzę do tego w inny sposób; po pierwsze, nigdy nie mówić NIE (da
> się), bo wszystko jest kwestią czasu, czytaj kasy.
>
> Poza tym zauważ (co prawda nie znam kontekstu, czyli co ta za system, jakie
> obciążenie ile i jakie dane, itd.), że zabawa z LIKE + CONVERT/CAST da radę
> w zadowalającym czasie dla typowych zestawów (kilka do kilkudziesięciu tyś
> rekordów) danych w dzisiejszym systemie ERP. I da się to zaprogramować
> uniwersalnie.
>
> Sprawdziłem, zaimplementowałem i wdrożyłem - jest OK. Czasem wymagana jest
> preselekcja danych do wyszukiwania (aby odrzucić nieistotne rekordu, np.
> archiwalne), ale i tak jest lepiej niż standardowe formularze do wyszukiwania.
>
W końcu ktoś z sensem. Nie bacząc na siebie :),  co sensu nie wyklucza - 
napisał. Sprzeczał bym się jedynie w kwestiach kasy (taki stereotyp - nie 
najważniejsza), dla mnie sumienie, sen.

-- 
Artur
0 weeks 0 days 12 hours 50 minutes 9 seconds and 148 milliseconds.
"pl.comp.bazy-danych"

W dniu 2015-02-22 o 13:49, M.M. pisze:
> On Sunday, February 22, 2015 at 10:10:11 AM UTC+1, PaSkol wrote:
>> W dniu 2015-02-21 o 20:22, M.M. pisze:
>>> Wybacz, ale nadal nie rozumiem, co ma wspólnego przytoczony przeze mnie
>>> tekst z szybszymi złączeniami. Uporządkowanie danych pomaga wtedy, gdy
>>> po odczycie rekordu o numerze (fizycznym) N, jest duże prawdopodobieństwo
>>> odczytania rekordu o numerze N+1. W jakich złączeniach tak jest?
>>
>> Dla mnie szybkość złączenia, to szybkość z jaką otrzymam dane, które to
>> złączenie mi zapewnia. A wyjaśniłem wszak dlaczego dane w przypadku
>> indeksu klastrowego uzyskuje się szybciej.
> Myślę że się mylisz, myślę że jest podobnie. Zakładam że autorzy silników
> baz danych nie dali dupy. Mamy tabelę która ma powiedzmy 10^9 rekordów.
> Chcemy rekord:
>
> select * from tabela where pole=coś.

Ale podajesz zapytanie, w którym nie ma złączenia (join). Więc to 
zupełnie inna sytuacja. A nawet gdyby "pole" było kluczem i to w 
indeksie klastrowym, to - powtarzam do znudzenia - znajdując wartość 
klucza masz już załadowane także dane. To jak z książką telefoniczną, 
wybierasz strony na K i odnajdując Kowalskiego masz od razu jego numer 
telefonu, adres i co tam jeszcze w książce jest. Ale szukając - załóżmy 
(bo nie wiem czy tak jest w książce tel.) - po numerze korzystasz z 
indeksu na końcu książki telefonicznej, gdzie jest napisane, że kowalski 
jest na stronie 147 i tam sobie doszukujesz. Czyli w drugim przypadku 
najpierw indeks wg telefonów, a potem jeszcze przeniesienie się na 
konkretną stronę (w bazie będzie od razu do właściwego rekordu). Czyli 
tu są dwa działania, a tam jedno (bo ustawienie się na stronach od K to 
przejście przez stosowny poziom b-drzewa).

> Czyli wolniej. Więc baza powinna założyć zwykłe b-tree pomimo
> clustered.

Clustered to jest b-tree (skoro każdy indeks to b-tree). Tylko że na 
jego końcu (liściach) są dane, a nie wskazania na dane.

> Chętnie dowiem się co pomylilem w powyższym rozumowaniu.

Jest ono nieistotne. Szukając po kluczu, który posłużył do ułożenia 
indeksu klastrowego, po prostu przeszukujesz też niejako dane. Proponuję 
zapoznać się najpierw co to dokładnie jest indeks klastrowy i skąd taka 
jego siła.

>> Ustawia się na początku indeksu (pomińmy rozważania na poziomie
>> b-drzewa, traktujmy indeks logicznie).
> Nie wiem na czym polega traktowanie indesku logicznie.

Logicznie tj. nie fizycznie. Logicznie czyli jako mechanizm, który w 
szybki sposób pozwala dotrzeć do szukanej wartości.

>> Pobiera pierwsza wartość i
>> porównuje z oczekiwaną. Jeśli jest to wartość 1 to musi przejść przez
>> kolejne 100 rekordów (bo dane są ułożone w kolejności),
> Jeśli ma indeks, to nie musi. Często trafia w rekord z tą stówą już
> po 3-5 'dostępach do dysku'. Piszę w cudzyslowie, bo może być
> wszystko w RAM.

"Przejść" w sensie wyłuskania danych z indeksu klastrowego. Szukał 
setnego, musiał (po standardowym przejściu przez poziomy b-drzewa) 
pominąć te dane, które są wcześniej.

>> W MSSQL
>> silnik bazy danych nie wylicza sobie bezpośrednio pozycji rekordu, on
>> potrafi przeskakiwać kolejne rekordy (bo wie jaki jest rozmiar każdego z
>> nich z osobna), aby dotrzeć do oczekiwanej wartości. Nie wylicza też z
>> powodów, o których już sam pisałeś - mogą być dziury w wartościach
>> klucza. Nie ma wyjścia - trzeba przeszukać całość, ale można tylko
>> wybrane fragmenty.
> Chyba piszesz o dwoch rzeczach, a ja nie chwytam kiedy o której. Raz
> piszesz że przeskakuje, drugi raz że musi szykać calość. Sorrki, nie
> kumam.

Bo po prostu nie rozumiesz co to jest indeks klastrowy.

>> Pod adresem, z którego przytoczono fragment o indeksach klastrowych jest
>> podany przykład takiej struktury w świecie rzeczywistym: to książka
>> telefoniczna, w której abonenci są ułożeni alfabetycznie. Odszukanie
>> konkretnego nazwiska polega zatem na przejrzeniu kilku stron poczynając
>> od tej, na której zaczynają się nazwiska na daną literę.
> Ale można pszeszukiwać inaczej, zwłaszcza gdy szuka algorytm na kompie, a
> nie czlowiek w książce.

Rzecz w tym, że algorytm szuka dokładnie tak samo jak człowiek. Dlatego 
właśnie podaje się analogię do książki telefonicznej. Książka _jest_ 
indeksem klastrowym.

>> No i? Jak potem bez odpowiedniej wiedzy dojdziesz, dlaczego działają raz
>> wolno a raz szybko (jak pytasz poniżej)?
> Ja jak dojdę? Metodą intuicji, prób i błędów. Zwykle robię coś na 2-3
> sposoby i wybieram ten który najszybciej działa. Jeśli cała baza jest w
> ram, jeśli zapytanie tylko odczytuje dane, to co ekspert zrobi
> lepiej? Ma lepiej wypracowaną intuicję i sprawdzi jeszcze 2 sposoby?

Ekspert nie będzie się opierał na intuicji. Sprawdzi na jakich danych 
operuje zapytanie. Jeśli okaże się, np. że zamiast varcharów stosowane 
są chary, ale i tak wszystkie wartości w nich umieszczane zajmują max 
50% założonej dla nich przestrzeni, to sprawdzi co tak naprawdę ma być 
tam przechowywane, dostosuje rozmiar varchara i zamieni chary na 
varchary. Doprowadzi to do sytuacji, gdzie wczytanie 1000 rekordów nie 
będzie wymagało odczytu tylu stron co poprzednio (bo więcej rekordów 
zmieści się na stronie). To jest realne zmniejszenie ilości odczytów z 
dysku. To jest także lepsze wykorzystanie bufora na dane.

>>> 3) warto usunąć testy poprawności danych - wiadomo kosztem jakiego ryzyka
>> Owszem można nie testować danych na poziomie bazy (bo można, a czasami
>> wręcz lepiej zrobić to wcześniej).
> Jeśli testujesz klucze obce to i tak i tak musi być dostęp do danych. No
> chyba że w programie masz kopię kluczy.

Co to znaczy testować klucze obce? Czy o to nie dbają więzy 
integralności (constraints)? Ja pisząc o testowaniu miałem na myśli 
sprawdzane poprawności danych na poziomie aplikacji (nie wpisujemy reguł 
do bazy - choć ona to umożliwia).

>>> 4) warto kupić sobie kontroler z bateryjnym podtrzymywaniem bufora zapisu
>>
>> A to akurat z wydajnością niewiele ma wspólnego
> Jak dasz buforowany zapis bez podtrzymywania bateryjnego, to w wyniku
> awarii zasilania co będzie?

Buforowany zapis? Wg mnie to strzelanie bazie danych w kolano, bo 
uniemożliwiamy jej zapewnienie transakcyjności. To już lepsze są ssd i 
podtrzymywanie zasilania serwera. Chyba, że czegoś nie rozumiem.

>>> A jak to nadal nie pomaga, to co Ci da informacja, ze varchar jest tak
>>> czy inaczej zaimplementowany?
>>
>> A po co w ogóle wprowadzono varchar? Gdyby nie było potrzebne, to by go
>> po prostu nie było. Okazało się jednak, że jest wręcz nieodzowne. Zatem
>> varchar, który varcharem nie jest to jak mieć randkę z transwestytą,
>> choć zamierzaliśmy z kobietą.
> Ale nie piszemy o przydatności w ogóle varchar, tylko o optymalizacji
> takich drobiazgów jak varchar.

To wyjaśniłem już wyżej.

>> Nie mam na myśli podniesienie, mam na myśli obniżenie. Po prostu już na
>> wstępie masz bazę, która wymaga większych zasobów niż to konieczne.
> I z powodu varchar nie podniesiesz istotnie wydajności tamtymi 6 punktami?
> Chciałbym to zobaczyć.

Być może podniesiesz, ale trzeba brać pod uwagę efekt skali. Może się 
okazać, że do obsługi 10 razy większej ilości użytkowników trzeba znowu 
rozbudować sprzęt, aby przechowywał on niepotrzebną do niczego 
przestrzeń. I nie wystarczy 1 TB RAM.

> A dublowane indeksy, to raczej przedszkole, do tego eksperta chyba nie trzeba?

Ale nie takie oczywiste dublowane indeksy, ale takie, które niczego nie 
wnoszą, bo choć opierają się na innej regule, to i tak optymalizator ich 
nie wykorzystuje, bo ma dwa lepsze do tego celu.

>> Nie odebrałem tego w ten sposób. Czyli chciałbym przechowywać kod
>> paskowy na Int64?
> Rozmawialiśmy o indeksach naturalnycyh, jak pesel, kod paskowy, albo
> nazwa systematyczna gatunku. Odpowiedziałem, że pomimo istnienia
> indeksów naturalnych, używam klucza własnego int64. Może robię
> głupio, oczekiwałem krytyki w kierunku klucz narutalny vs sztuczny int64.

Klucze naturalne stosuje się rzadko, zazwyczaj tylko wtedy, gdy daje to 
uzasadniony zysk wydajnościowy. Ze znanych mi przypadków taki klucz 
założono na kodzie towaru, bo kartoteka szła w miliony, a czas 
wystawiania dokumentu na podstawie tegoż symbolu był wybitnie istotny 
(sprzedaż miała się odbywać szybko, klienci nie lubią czekać).

> Więc może rozwiązanie: 'zawsze klucz sztuczny na int32 lub int64' -
> jest jednak dobre?

W większości przypadków tak, z tym że int64 tylko wtedy, gdy zakładamy, 
że przekroczymy zakres int32.

>> Nie bardzo też widzę związek z szybkością komputerów i
>> wyczerpaniem Int32. To przecież zależy od rodzaju danych (ich zakresu).
> Na wolnych kompach trzeba dłużej liczyć, aby wyczerpać int32.

Ale klucz sztuczny nie jest wyliczany. On narasta i to w długich 
okresach czasu, więc co ma do tego szybkość komputera?

> Generalnie posdumowując całość, chciałbym się naocznie przekonać o tym
> co piszesz. Tak w teoretycznej rozmowie jakoś nie mogę uwierzyć.

Poleciłbym Ci tę prezentację 
(https://www.youtube.com/watch?v=HqzsH_49b-U), ale jak widzę coś się w 
niej zepsuło, a szkoda, bo z tego co pamiętam była dokładnie na omawiany 
temat. Możesz ewentualnie zajrzeć tutaj, choć jest bardziej o tym jak 
działa estymacja optymalizatora bazy danych 
(https://www.youtube.com/watch?v=FbEHdkxR2XI).


-- 
PaSkol (paskol.robi.to)

On Sunday, February 22, 2015 at 7:08:44 PM UTC+1, PaSkol wrote:
> W dniu 2015-02-22 o 13:49, M.M. pisze:
> > On Sunday, February 22, 2015 at 10:10:11 AM UTC+1, PaSkol wrote:
> >> W dniu 2015-02-21 o 20:22, M.M. pisze:
> >>> Wybacz, ale nadal nie rozumiem, co ma wspólnego przytoczony przeze mnie
> >>> tekst z szybszymi złączeniami. Uporządkowanie danych pomaga wtedy, gdy
> >>> po odczycie rekordu o numerze (fizycznym) N, jest duże prawdopodobieństwo
> >>> odczytania rekordu o numerze N+1. W jakich złączeniach tak jest?
> >>
> >> Dla mnie szybkość złączenia, to szybkość z jaką otrzymam dane, które to
> >> złączenie mi zapewnia. A wyjaśniłem wszak dlaczego dane w przypadku
> >> indeksu klastrowego uzyskuje się szybciej.
> > Myślę że się mylisz, myślę że jest podobnie. Zakładam że autorzy silników
> > baz danych nie dali dupy. Mamy tabelę która ma powiedzmy 10^9 rekordów.
> > Chcemy rekord:
> >
> > select * from tabela where pole=coś.
> 
> Ale podajesz zapytanie, w którym nie ma złączenia (join). Więc to 
> zupełnie inna sytuacja.
Analogiczne, wręcz takie samo wyszukanie zachodzi przy złączeniach.

> A nawet gdyby "pole" było kluczem i to w indeksie klastrowym,
Właśnie, o to mi chidzło.

> to - powtarzam do znudzenia - znajdując wartość klucza masz już 
> załadowane także dane. 
Chwila. Są rożne odmiany b-tree. Jeśli zakłądamy zwykły indeks
(nie klastrowy) oparty o b-tree, to też w tym indeksie mogą być dane.
Jedne rodzaje b-tree trzymają dane w liściach, aby, tak jak napisałeś,
mieć od razu wartość danych. Inne rodzeje trzymają tylko odnośniki, 
aby maksmyalizować brenchfactor. Nie mam pojęcia jakich rodzajów 
używają popularne bazy danych.


> To jak z książką telefoniczną, 
> wybierasz strony na K i odnajdując Kowalskiego masz od razu jego numer 
> telefonu, adres i co tam jeszcze w książce jest. 
Nie wiem czy nie jestem w blędzie, ale tak właśnie rozumiem indeks klastrowy.

> Ale szukając - załóżmy 
> (bo nie wiem czy tak jest w książce tel.) - po numerze korzystasz z 
> indeksu na końcu książki telefonicznej, gdzie jest napisane, że kowalski 
> jest na stronie 147 i tam sobie doszukujesz. 
Tak z kolei sobie wyobrażam nie-klastrowe indeksy.

> Czyli w drugim przypadku 
> najpierw indeks wg telefonów, a potem jeszcze przeniesienie się na 
> konkretną stronę (w bazie będzie od razu do właściwego rekordu). 
Po pierwsze, potem tak nie musi być, bo są odmiany b-tree z danymi
w liściach. Po drugie, nawet jeśli potem tak jest, to koszt jest
równoważny jednemu dostępowi do dysku - czyli jest pomijalnie mały.


> Czyli 
> tu są dwa działania, a tam jedno (bo ustawienie się na stronach od K to 
> przejście przez stosowny poziom b-drzewa).
Ale to drugie działanie ma koszt prawie zerowy. To o czym piszesz, ma
kolosalne znaczenie przy sekwencyjnym dostępie, a nie przy złączeniach.


> > Czyli wolniej. Więc baza powinna założyć zwykłe b-tree pomimo
> > clustered.
> 
> Clustered to jest b-tree (skoro każdy indeks to b-tree). Tylko że na 
> jego końcu (liściach) są dane, a nie wskazania na dane.
Nie wiem czy tak można powiedzieć... b-tree to struktura danych.
Clustered to opcja przy zakładaniu indeksu. Sorry, ja widzę dwie
całkiem różne rzeczy.


> 
> > Chętnie dowiem się co pomylilem w powyższym rozumowaniu.
> 
> Jest ono nieistotne. Szukając po kluczu, który posłużył do ułożenia 
> indeksu klastrowego, po prostu przeszukujesz też niejako dane. Proponuję 
> zapoznać się najpierw co to dokładnie jest indeks klastrowy i skąd taka 
> jego siła.
Niezgodzę się, powody opisałem powyżej: b-tree też może mieć kopię
danychy, a ta kopia w niewielkim stopniu wpływa na wydajność.


> >> Ustawia się na początku indeksu (pomińmy rozważania na poziomie
> >> b-drzewa, traktujmy indeks logicznie).
> > Nie wiem na czym polega traktowanie indesku logicznie.
> 
> Logicznie tj. nie fizycznie. Logicznie czyli jako mechanizm, który w 
> szybki sposób pozwala dotrzeć do szukanej wartości.
Hmmm no dobra.


> 
> >> Pobiera pierwsza wartość i
> >> porównuje z oczekiwaną. Jeśli jest to wartość 1 to musi przejść przez
> >> kolejne 100 rekordów (bo dane są ułożone w kolejności),
> > Jeśli ma indeks, to nie musi. Często trafia w rekord z tą stówą już
> > po 3-5 'dostępach do dysku'. Piszę w cudzyslowie, bo może być
> > wszystko w RAM.
> 
> "Przejść" w sensie wyłuskania danych z indeksu klastrowego. Szukał 
> setnego, musiał (po standardowym przejściu przez poziomy b-drzewa) 
> pominąć te dane, które są wcześniej.
Czyli musiał przejść przez b-drzewo a nie przez dane - to się zgodzę.
Przez dane przeskakuje dzięki b-tree.


> 
> >> W MSSQL
> >> silnik bazy danych nie wylicza sobie bezpośrednio pozycji rekordu, on
> >> potrafi przeskakiwać kolejne rekordy (bo wie jaki jest rozmiar każdego z
> >> nich z osobna), aby dotrzeć do oczekiwanej wartości. Nie wylicza też z
> >> powodów, o których już sam pisałeś - mogą być dziury w wartościach
> >> klucza. Nie ma wyjścia - trzeba przeszukać całość, ale można tylko
> >> wybrane fragmenty.
> > Chyba piszesz o dwoch rzeczach, a ja nie chwytam kiedy o której. Raz
> > piszesz że przeskakuje, drugi raz że musi szykać calość. Sorrki, nie
> > kumam.
> 
> Bo po prostu nie rozumiesz co to jest indeks klastrowy.
Pisałem jak ja rozumiem. Jest to indeks, który dodatkowo wymusza
fizyczną reorganizację danych w tabeli.


> >> Pod adresem, z którego przytoczono fragment o indeksach klastrowych jest
> >> podany przykład takiej struktury w świecie rzeczywistym: to książka
> >> telefoniczna, w której abonenci są ułożeni alfabetycznie. Odszukanie
> >> konkretnego nazwiska polega zatem na przejrzeniu kilku stron poczynając
> >> od tej, na której zaczynają się nazwiska na daną literę.
> > Ale można pszeszukiwać inaczej, zwłaszcza gdy szuka algorytm na kompie, a
> > nie czlowiek w książce.
> 
> Rzecz w tym, że algorytm szuka dokładnie tak samo jak człowiek. Dlatego 
> właśnie podaje się analogię do książki telefonicznej. Książka _jest_ 
> indeksem klastrowym.
Pewnie chodziło Ci jeszcze o to, że strona książki, to strona na 
dysku? Jeśli tak, to zgoda. Sorrki, ale togo się nie domyśliłem od razu. 

> 
> >> No i? Jak potem bez odpowiedniej wiedzy dojdziesz, dlaczego działają raz
> >> wolno a raz szybko (jak pytasz poniżej)?
> > Ja jak dojdę? Metodą intuicji, prób i błędów. Zwykle robię coś na 2-3
> > sposoby i wybieram ten który najszybciej działa. Jeśli cała baza jest w
> > ram, jeśli zapytanie tylko odczytuje dane, to co ekspert zrobi
> > lepiej? Ma lepiej wypracowaną intuicję i sprawdzi jeszcze 2 sposoby?
> 
> Ekspert nie będzie się opierał na intuicji. Sprawdzi na jakich danych 
> operuje zapytanie. Jeśli okaże się, np. że zamiast varcharów stosowane 
> są chary, ale i tak wszystkie wartości w nich umieszczane zajmują max 
> 50% założonej dla nich przestrzeni, to sprawdzi co tak naprawdę ma być 
> tam przechowywane, dostosuje rozmiar varchara i zamieni chary na 
> varchary. Doprowadzi to do sytuacji, gdzie wczytanie 1000 rekordów nie 
> będzie wymagało odczytu tylu stron co poprzednio (bo więcej rekordów 
> zmieści się na stronie). To jest realne zmniejszenie ilości odczytów z 
> dysku. To jest także lepsze wykorzystanie bufora na dane.
Nie zgodzę się. Taki drobiazg umiem zrobić ja, a nie jestem ekspertem.


> >>> 3) warto usunąć testy poprawności danych - wiadomo kosztem jakiego ryzyka
> >> Owszem można nie testować danych na poziomie bazy (bo można, a czasami
> >> wręcz lepiej zrobić to wcześniej).
> > Jeśli testujesz klucze obce to i tak i tak musi być dostęp do danych. No
> > chyba że w programie masz kopię kluczy.
> 
> Co to znaczy testować klucze obce? Czy o to nie dbają więzy 
> integralności (constraints)? 
Tak, chodziło mi też o testowanie więzów integralności. Można to
wyłączyć.

> Ja pisząc o testowaniu miałem na myśli 
> sprawdzane poprawności danych na poziomie aplikacji (nie wpisujemy reguł 
> do bazy - choć ona to umożliwia).
To w moich pomiarach zajmuje mało czasu. Za to kolosalnie dużo czasu
zajmuje testowanie kluczy obcych przy insertach.



> >>> 4) warto kupić sobie kontroler z bateryjnym podtrzymywaniem bufora zapisu
> >>
> >> A to akurat z wydajnością niewiele ma wspólnego
> > Jak dasz buforowany zapis bez podtrzymywania bateryjnego, to w wyniku
> > awarii zasilania co będzie?
> 
> Buforowany zapis? Wg mnie to strzelanie bazie danych w kolano, bo 
> uniemożliwiamy jej zapewnienie transakcyjności. To już lepsze są ssd i 
> podtrzymywanie zasilania serwera. Chyba, że czegoś nie rozumiem.
Transakcje tak samo są możliwe. Buforowany zapis, gdy bufor straci zasilanie,
niesie ryzyko utraty spójności bazy. Dlatego stosuje się podtrzymywanie 
bateryjne tego bufora. Mądrzejsze kontrolery ponoć
same testują jakość baterii i same wyłączają buforowany zapis, gdy
bateria, np. po 1-2 latach pracy, straci swoją pojemność.



> >>> A jak to nadal nie pomaga, to co Ci da informacja, ze varchar jest tak
> >>> czy inaczej zaimplementowany?
> >>
> >> A po co w ogóle wprowadzono varchar? Gdyby nie było potrzebne, to by go
> >> po prostu nie było. Okazało się jednak, że jest wręcz nieodzowne. Zatem
> >> varchar, który varcharem nie jest to jak mieć randkę z transwestytą,
> >> choć zamierzaliśmy z kobietą.
> > Ale nie piszemy o przydatności w ogóle varchar, tylko o optymalizacji
> > takich drobiazgów jak varchar.
> 
> To wyjaśniłem już wyżej.
Moim zdaniem to jest walka o pojedyncze milisekundy, nie wiem czy
gra jest warta świeczki.

> 
> >> Nie mam na myśli podniesienie, mam na myśli obniżenie. Po prostu już na
> >> wstępie masz bazę, która wymaga większych zasobów niż to konieczne.
> > I z powodu varchar nie podniesiesz istotnie wydajności tamtymi 6 punktami?
> > Chciałbym to zobaczyć.
> 
> Być może podniesiesz, ale trzeba brać pod uwagę efekt skali. Może się 
> okazać, że do obsługi 10 razy większej ilości użytkowników trzeba znowu 
> rozbudować sprzęt, aby przechowywał on niepotrzebną do niczego 
> przestrzeń. I nie wystarczy 1 TB RAM.
Moim zdaniem, 10 razy więcej użytkowników dzięki optymalizacji vchar, to
fikcja. Myślę, że to może dać 1% więcej użytkowników. No chyba że ktoś
naprawdę nieudacznie te vchary zrobi. Może dla uściślenia przypomnę.
Chodzi o bazę zrobioną przez rozsądną osobe, która w miarę się zna, a
potem o ulepszenia wprowadzone przez eksperta. Nie chodzi o bazę
zrobioną przez totalnego lamera i potem ulepszoną przez eksperta - bo 
tak to może faktycznie 10 razy więcej userów...


> 
> > A dublowane indeksy, to raczej przedszkole, do tego eksperta chyba nie trzeba?
> 
> Ale nie takie oczywiste dublowane indeksy, ale takie, które niczego nie 
> wnoszą, bo choć opierają się na innej regule, to i tak optymalizator ich 
> nie wykorzystuje, bo ma dwa lepsze do tego celu.
Tyle że takie indeksy też dużo nie spowalniają. Trochę spada wydajność
insertów. Poza tym wywalenie nieużywanych indeksów, to też zadanie
dla przeciętniaka, a nie dla eksperta.


> >> Nie odebrałem tego w ten sposób. Czyli chciałbym przechowywać kod
> >> paskowy na Int64?
> > Rozmawialiśmy o indeksach naturalnycyh, jak pesel, kod paskowy, albo
> > nazwa systematyczna gatunku. Odpowiedziałem, że pomimo istnienia
> > indeksów naturalnych, używam klucza własnego int64. Może robię
> > głupio, oczekiwałem krytyki w kierunku klucz narutalny vs sztuczny int64.
> 
> Klucze naturalne stosuje się rzadko, zazwyczaj tylko wtedy, gdy daje to 
> uzasadniony zysk wydajnościowy. Ze znanych mi przypadków taki klucz 
> założono na kodzie towaru, bo kartoteka szła w miliony, a czas 
> wystawiania dokumentu na podstawie tegoż symbolu był wybitnie istotny 
> (sprzedaż miała się odbywać szybko, klienci nie lubią czekać).
Ciekawe ile zaoszczędzono czasu na tym jednym polu int32 lub int64 w
skali całego rekordu. Ciekawe ile by zaoszczędzono, jakby program
buforował inserty i wysłał np. w paczkach po 30 insertów. Ciekawe 
jaki byłby zysk, jakby dziennik dać na specjalnym dysku, no i 
co by się działo, jakby buforować zapis - zwróć uwagę, że to nadal
tanie i łatwe techniki.


> > Więc może rozwiązanie: 'zawsze klucz sztuczny na int32 lub int64' -
> > jest jednak dobre?
> 
> W większości przypadków tak, z tym że int64 tylko wtedy, gdy zakładamy, 
> że przekroczymy zakres int32.
Ok.



> >> Nie bardzo też widzę związek z szybkością komputerów i
> >> wyczerpaniem Int32. To przecież zależy od rodzaju danych (ich zakresu).
> > Na wolnych kompach trzeba dłużej liczyć, aby wyczerpać int32.
> 
> Ale klucz sztuczny nie jest wyliczany. On narasta i to w długich 
> okresach czasu, więc co ma do tego szybkość komputera?
Chodzilo o to, że komputer 10 razy wolniejszy, musi pracować 10
razy dłużej, aby przepełnić int32 :) To szczegół, nic on nie
wnosi, nie ciągnijmy.


> > Generalnie posdumowując całość, chciałbym się naocznie przekonać o tym
> > co piszesz. Tak w teoretycznej rozmowie jakoś nie mogę uwierzyć.
> 
> Poleciłbym Ci tę prezentację 
> (https://www.youtube.com/watch?v=HqzsH_49b-U), ale jak widzę coś się w 
> niej zepsuło, a szkoda, bo z tego co pamiętam była dokładnie na omawiany 
> temat. Możesz ewentualnie zajrzeć tutaj, choć jest bardziej o tym jak 
> działa estymacja optymalizatora bazy danych 
> (https://www.youtube.com/watch?v=FbEHdkxR2XI).
Dzięki, spojrzę.

Pozdrawiam

W dniu 2015-02-22 o 19:51, M.M. pisze:
> Chwila. Są rożne odmiany b-tree. Jeśli zakłądamy zwykły indeks
> (nie klastrowy) oparty o b-tree, to też w tym indeksie mogą być dane.
> Jedne rodzaje b-tree trzymają dane w liściach, aby, tak jak napisałeś,
> mieć od razu wartość danych. Inne rodzeje trzymają tylko odnośniki,
> aby maksmyalizować brenchfactor. Nie mam pojęcia jakich rodzajów
> używają popularne bazy danych.

Indeks klastrowy w MSSQL, z tego co mi wiadomo, ma w liściach po prostu 
wiersze tabeli.

>> To jak z książką telefoniczną,
>> wybierasz strony na K i odnajdując Kowalskiego masz od razu jego numer
>> telefonu, adres i co tam jeszcze w książce jest.
> Nie wiem czy nie jestem w blędzie, ale tak właśnie rozumiem indeks klastrowy.

No i tak ten indeks jest zrealizowany. Znalazłeś Kowalskiego, ale przy 
okazji także wszystko co książka (analogicznie - tabela) na jego temat 
gromadzi.

>> Ale szukając - załóżmy
>> (bo nie wiem czy tak jest w książce tel.) - po numerze korzystasz z
>> indeksu na końcu książki telefonicznej, gdzie jest napisane, że kowalski
>> jest na stronie 147 i tam sobie doszukujesz.
> Tak z kolei sobie wyobrażam nie-klastrowe indeksy.

I tak właśnie są one zbudowane (choć MSSQL-u prowadzą nie do adresu 
wiersza, a do jego pozycji w indeksie klastrowym).

>> Czyli w drugim przypadku
>> najpierw indeks wg telefonów, a potem jeszcze przeniesienie się na
>> konkretną stronę (w bazie będzie od razu do właściwego rekordu).
> Po pierwsze, potem tak nie musi być, bo są odmiany b-tree z danymi
> w liściach. Po drugie, nawet jeśli potem tak jest, to koszt jest
> równoważny jednemu dostępowi do dysku - czyli jest pomijalnie mały.

Tak, ale cały czas dyskutujemy o indeksie klastrowym. A te inne indeksy 
rozpatrujemy standardowo i nawet jeśli miałyby dodatkowo zawierać dane, 
to przecież nie wszystkie, jakie w tabeli są (więc będą pasować tylko 
dla specyficznej listy kolumn w select). W indeksie klastrowym dane 
zawsze są pod ręką.

>> Czyli
>> tu są dwa działania, a tam jedno (bo ustawienie się na stronach od K to
>> przejście przez stosowny poziom b-drzewa).
> Ale to drugie działanie ma koszt prawie zerowy. To o czym piszesz, ma
> kolosalne znaczenie przy sekwencyjnym dostępie, a nie przy złączeniach.

Wg mnie niezerowy, bo trzeba sięgnąć po strony danych - czyli odczytać 
je z dysku. Tak jak w przykładzie z książką telefoniczną. Najpierw 
trzeba było zajrzeć na koniec, a potem wrócić na odpowiednią stronę. I 
przy złączeniach musimy dla indeksu nieklastrowego powtórzyć 
wielokrotnie taką operację. Oczywiście część stron zdąży się nam 
załadować wcześniej i będziemy mogli je ponownie wykorzystać, ale jeśli 
te strony są nieoptymalnie zapełnione (np. puste chary zamiast 
varcharów) może się okazać, że trzeba je było wyrzucić żeby pobrać w ich 
miejsce inne strony.

>> Clustered to jest b-tree (skoro każdy indeks to b-tree). Tylko że na
>> jego końcu (liściach) są dane, a nie wskazania na dane.
> Nie wiem czy tak można powiedzieć... b-tree to struktura danych.
> Clustered to opcja przy zakładaniu indeksu. Sorry, ja widzę dwie
> całkiem różne rzeczy.

Tak to jest przedstawiane na schematach, jest trójkąt wizualizujący 
b-tree i do jego podstawy są przypięte dane - wiersze tabeli. Te 
wiersze, jeśli dobrze pamiętam, są ostatnim poziomem tego drzewa (stąd 
pisałem o "liściach").

>>> Chętnie dowiem się co pomylilem w powyższym rozumowaniu.
>>
>> Jest ono nieistotne. Szukając po kluczu, który posłużył do ułożenia
>> indeksu klastrowego, po prostu przeszukujesz też niejako dane. Proponuję
>> zapoznać się najpierw co to dokładnie jest indeks klastrowy i skąd taka
>> jego siła.
> Niezgodzę się, powody opisałem powyżej: b-tree też może mieć kopię
> danychy, a ta kopia w niewielkim stopniu wpływa na wydajność.

Wg mnie nawet ta kopia wpływa - po co zresztą by wymyślano indeks z 
załączanymi danymi, jeśli nie po to, aby przy użyciu indeksu mieć dostęp 
właśnie do tych konkretnych danych.

>> "Przejść" w sensie wyłuskania danych z indeksu klastrowego. Szukał
>> setnego, musiał (po standardowym przejściu przez poziomy b-drzewa)
>> pominąć te dane, które są wcześniej.
> Czyli musiał przejść przez b-drzewo a nie przez dane - to się zgodzę.
> Przez dane przeskakuje dzięki b-tree.

Jak pisałem wcześniej - ostatni poziom indeksu klastrowego to de facto 
dane, a nie jedynie wskazania na nie. Czyli kolejne pozycje tego poziomu 
są od siebie oddalone o rozmiar wiersza - stąd te skoki i przechodzenie 
przez dane (analogicznie do wertowanie stron w celu znalezienia 
Kucharskiego, który powinien być gdzieś dalej po Kowalskim).

>> Bo po prostu nie rozumiesz co to jest indeks klastrowy.
> Pisałem jak ja rozumiem. Jest to indeks, który dodatkowo wymusza
> fizyczną reorganizację danych w tabeli.

A to jest "dwa w jednym" (przynajmniej w MSSQL-u).

>> Ekspert nie będzie się opierał na intuicji. Sprawdzi na jakich danych
>> operuje zapytanie. Jeśli okaże się, np. że zamiast varcharów stosowane
>> są chary, ale i tak wszystkie wartości w nich umieszczane zajmują max
>> 50% założonej dla nich przestrzeni, to sprawdzi co tak naprawdę ma być
>> tam przechowywane, dostosuje rozmiar varchara i zamieni chary na
>> varchary. Doprowadzi to do sytuacji, gdzie wczytanie 1000 rekordów nie
>> będzie wymagało odczytu tylu stron co poprzednio (bo więcej rekordów
>> zmieści się na stronie). To jest realne zmniejszenie ilości odczytów z
>> dysku. To jest także lepsze wykorzystanie bufora na dane.
> Nie zgodzę się. Taki drobiazg umiem zrobić ja, a nie jestem ekspertem.

Podałem akurat taki przykład, bo wynikał z kontekstu dyskusji. 
Przypadków może być więcej, postaram się skontaktować z liderami 
warszawskiej PLSSUG, możliwie, że wrzucą ponownie wideo z tej 
uszkodzonej prezentacji, którą polecałem.

>>> Ale nie piszemy o przydatności w ogóle varchar, tylko o optymalizacji
>>> takich drobiazgów jak varchar.
>>
>> To wyjaśniłem już wyżej.
> Moim zdaniem to jest walka o pojedyncze milisekundy, nie wiem czy
> gra jest warta świeczki.

Kiedy okazuje się, że trzeba z tego powodu czytać wiele stron (w tym 
ponownie te, które już odczytano), wówczas nie są to milisekundy. A tak 
może być przy odpowiednio intensywnym wielodostępie i niewystarczającej 
na niego pamięci (czasami okazuje się, że wystarczy kilkunastu 
magazynierów z handheldami kompletujących zamówienia).

>>>> Nie mam na myśli podniesienie, mam na myśli obniżenie. Po prostu już na
>>>> wstępie masz bazę, która wymaga większych zasobów niż to konieczne.
>>> I z powodu varchar nie podniesiesz istotnie wydajności tamtymi 6 punktami?
>>> Chciałbym to zobaczyć.
>>
>> Być może podniesiesz, ale trzeba brać pod uwagę efekt skali. Może się
>> okazać, że do obsługi 10 razy większej ilości użytkowników trzeba znowu
>> rozbudować sprzęt, aby przechowywał on niepotrzebną do niczego
>> przestrzeń. I nie wystarczy 1 TB RAM.
> Moim zdaniem, 10 razy więcej użytkowników dzięki optymalizacji vchar, to
> fikcja. Myślę, że to może dać 1% więcej użytkowników. No chyba że ktoś
> naprawdę nieudacznie te vchary zrobi. Może dla uściślenia przypomnę.
> Chodzi o bazę zrobioną przez rozsądną osobe, która w miarę się zna, a
> potem o ulepszenia wprowadzone przez eksperta. Nie chodzi o bazę
> zrobioną przez totalnego lamera i potem ulepszoną przez eksperta - bo
> tak to może faktycznie 10 razy więcej userów...

10 razy to rząd wielkości, dla 1000 może się jeszcze nic nie dziać, ale 
już dla 10 tys...


>>> A dublowane indeksy, to raczej przedszkole, do tego eksperta chyba nie trzeba?
>>
>> Ale nie takie oczywiste dublowane indeksy, ale takie, które niczego nie
>> wnoszą, bo choć opierają się na innej regule, to i tak optymalizator ich
>> nie wykorzystuje, bo ma dwa lepsze do tego celu.
> Tyle że takie indeksy też dużo nie spowalniają. Trochę spada wydajność
> insertów. Poza tym wywalenie nieużywanych indeksów, to też zadanie
> dla przeciętniaka, a nie dla eksperta.

Tylko że Ty patrzysz z punktu widzenia administratora bazy, a nie 
typowego programisty, który niespecjalnie się przejmuje bazą danych. To 
dla niego taka czarna skrzynka (jak dla Ciebie indeks), do której po 
prostu wrzuca dane. I on może nawet przypadkiem założyć taki powielający 
indeks, ale nigdy nie zajrzy do bazy aby sprawdzić, że jest 
niepotrzebny. Więc często i gęsto tacy spece od baz danych robią takie 
proste rzeczy. Ja zresztą takim specem nie jestem, natomiast oglądałem 
wystąpienia takowych (jakieś 3 lata temu) i to było bardzo pouczające. 
To był m.in. człowiek, którzy optymalizuje bazy dla Allegro.

>> Klucze naturalne stosuje się rzadko, zazwyczaj tylko wtedy, gdy daje to
>> uzasadniony zysk wydajnościowy. Ze znanych mi przypadków taki klucz
>> założono na kodzie towaru, bo kartoteka szła w miliony, a czas
>> wystawiania dokumentu na podstawie tegoż symbolu był wybitnie istotny
>> (sprzedaż miała się odbywać szybko, klienci nie lubią czekać).
> Ciekawe ile zaoszczędzono czasu na tym jednym polu int32 lub int64 w
> skali całego rekordu. Ciekawe ile by zaoszczędzono, jakby program
> buforował inserty i wysłał np. w paczkach po 30 insertów. Ciekawe
> jaki byłby zysk, jakby dziennik dać na specjalnym dysku, no i
> co by się działo, jakby buforować zapis - zwróć uwagę, że to nadal
> tanie i łatwe techniki.

Wydaje mi się, że to było jedyne najbardziej optymalne rozwiązanie - ci 
dwaj goście, którzy robią ową uszkodzoną prezentację się tym zajmowali, 
więc (obaj MVP) ja raczej nie mam wątpliwości, że przegapiliby coś lepszego.


-- 
PaSkol (paskol.robi.to)

On Monday, February 23, 2015 at 9:54:07 PM UTC+1, PaSkol wrote:
> Indeks klastrowy w MSSQL, z tego co mi wiadomo, ma w liściach po prostu 
> wiersze tabeli.
Ok, w sumie jedno drugiego nie wyklucza. Tabela jest posorotwana (czytaj:
pod kolejnym adresem fizycznym są kolejne dane w kolejności sortowania).
Jednocześnie jest b-tree którego liśćmi są strony tej tabeli.


> >> To jak z książką telefoniczną,
> >> wybierasz strony na K i odnajdując Kowalskiego masz od razu jego numer
> >> telefonu, adres i co tam jeszcze w książce jest.
> > Nie wiem czy nie jestem w blędzie, ale tak właśnie rozumiem indeks klastrowy.
> 
> No i tak ten indeks jest zrealizowany. Znalazłeś Kowalskiego, ale przy 
> okazji także wszystko co książka (analogicznie - tabela) na jego temat 
> gromadzi.
Czyli w przybliżeniu mam dobre wyobrażenie na ten temat.

> 
> >> Ale szukając - załóżmy
> >> (bo nie wiem czy tak jest w książce tel.) - po numerze korzystasz z
> >> indeksu na końcu książki telefonicznej, gdzie jest napisane, że kowalski
> >> jest na stronie 147 i tam sobie doszukujesz.
> > Tak z kolei sobie wyobrażam nie-klastrowe indeksy.
> 
> I tak właśnie są one zbudowane (choć MSSQL-u prowadzą nie do adresu 
> wiersza, a do jego pozycji w indeksie klastrowym).
Ok, ale to drobna różnica, o czym poniżej.


> >> Czyli w drugim przypadku
> >> najpierw indeks wg telefonów, a potem jeszcze przeniesienie się na
> >> konkretną stronę (w bazie będzie od razu do właściwego rekordu).
> > Po pierwsze, potem tak nie musi być, bo są odmiany b-tree z danymi
> > w liściach. Po drugie, nawet jeśli potem tak jest, to koszt jest
> > równoważny jednemu dostępowi do dysku - czyli jest pomijalnie mały.
> 
> Tak, ale cały czas dyskutujemy o indeksie klastrowym. 
W sumie to nie tylko o tym. Rozmowa się rozwidliła.

> A te inne indeksy 
> rozpatrujemy standardowo i nawet jeśli miałyby dodatkowo zawierać dane, 
> to przecież nie wszystkie, jakie w tabeli są (więc będą pasować tylko 
> dla specyficznej listy kolumn w select). 
Tak, ale to w często jest lepsze, zwłaszcza gdy w trakice obliczeń
są brane pod uwagę tylko te dane zawarte wewnątrz indeksu. 

> W indeksie klastrowym dane zawsze są pod ręką.
Tak, ale może się okazać, że rekord ma np. 15 pól, a potrzebne są
tylko 2 pola. Wtedy pozostałe 13 pól w indeksie klastrowym zwyczajnie
zawadza. Można się ratować tabelą (dwu)kolumnową... ale tego
typu zabiegi potem utrudniają rozwój aplikacji.



> >> Czyli
> >> tu są dwa działania, a tam jedno (bo ustawienie się na stronach od K to
> >> przejście przez stosowny poziom b-drzewa).
> > Ale to drugie działanie ma koszt prawie zerowy. To o czym piszesz, ma
> > kolosalne znaczenie przy sekwencyjnym dostępie, a nie przy złączeniach.
> 
> Wg mnie niezerowy, bo trzeba sięgnąć po strony danych - czyli odczytać 
> je z dysku. 
Spójrz na to jak na koszt relatywny. Mamy zapytanie sql. Trzeba je
przesłać przez TCP-IP. Trzeba je sparsować/skompilować. Trzeba 
sprawdzić uprawneinia usera w bazie, w systemie operacyjnym, 
czasami także w aplikacji. Zwykle łączymy 2-3 a może 4 tabele. Często
zbędne rekordy da się szybciej odfiltrować. Część danych, albo
calość jest buforowana w RAM. W takich warunkach chcemy zaoszczędzić
jedno dociągnięcie danych z jednej tabeli. Ile to relatywnie przyspieszy?
Będzie to zysk chociaż 10%? Jak będzie dużo danych w RAM, to może
być zysk poniżej 1%. Nie wspominam tutaj jeszcze o koszcie 
sformatowania danych wyjściowych i wyświetlenia ich użytkownikowi. 
Ja bym się tym nie martwił. 

Mnie martwi co innego. Np. mam małą, testową bazę. Skompresowany
dump bazy zajmuje 300MB. Zatem całą baza mieści się w buforze RAM.
Wykonuję pewne zapytania SQL i mierzę czasy. Potem piszę analogiczną
aplikację w C++ i znowu mierzę czasy. Wychodzi że w C++ działą 10tys
razy szybciej. Dodaj jeszcze, że w C++ nie zmieniam struktury 
danych. W C++ normalnie trzymam tabele w RAM, czasami posortowane (odpowiednik
clustered), zakładam indeksy hash, albo red-black-tree. Bym
rozumiał, jakby baza działała 300 razy wolniej. Ale 10tys?


> Tak jak w przykładzie z książką telefoniczną. Najpierw 
> trzeba było zajrzeć na koniec, a potem wrócić na odpowiednią stronę. I 
> przy złączeniach musimy dla indeksu nieklastrowego powtórzyć 
> wielokrotnie taką operację. Oczywiście część stron zdąży się nam 
> załadować wcześniej i będziemy mogli je ponownie wykorzystać, ale jeśli 
> te strony są nieoptymalnie zapełnione (np. puste chary zamiast 
> varcharów) może się okazać, że trzeba je było wyrzucić żeby pobrać w ich 
> miejsce inne strony.
Tak, ale tabel w złączeniu mamy np. 4. Jeśli w jednej jest o 30% 
spacji za dużo, to koszt całego zapytania nie wzrośnie o 30%, tylko
proporcjonalnie do kosztu operacji na tej jednej tabeli. Naprawdę
to jest drobiazg.



> >> Clustered to jest b-tree (skoro każdy indeks to b-tree). Tylko że na
> >> jego końcu (liściach) są dane, a nie wskazania na dane.
> > Nie wiem czy tak można powiedzieć... b-tree to struktura danych.
> > Clustered to opcja przy zakładaniu indeksu. Sorry, ja widzę dwie
> > całkiem różne rzeczy.
> 
> Tak to jest przedstawiane na schematach, jest trójkąt wizualizujący 
> b-tree i do jego podstawy są przypięte dane - wiersze tabeli. Te 
> wiersze, jeśli dobrze pamiętam, są ostatnim poziomem tego drzewa (stąd 
> pisałem o "liściach").
Ok.


> >>> Chętnie dowiem się co pomylilem w powyższym rozumowaniu.
> >>
> >> Jest ono nieistotne. Szukając po kluczu, który posłużył do ułożenia
> >> indeksu klastrowego, po prostu przeszukujesz też niejako dane. Proponuję
> >> zapoznać się najpierw co to dokładnie jest indeks klastrowy i skąd taka
> >> jego siła.
> > Niezgodzę się, powody opisałem powyżej: b-tree też może mieć kopię
> > danychy, a ta kopia w niewielkim stopniu wpływa na wydajność.
> 
> Wg mnie nawet ta kopia wpływa - po co zresztą by wymyślano indeks z 
> załączanymi danymi, jeśli nie po to, aby przy użyciu indeksu mieć dostęp 
> właśnie do tych konkretnych danych.
Tak, wymyślono go właśnie po to. Ale ma on też wady. Rozgałęzienie w
liściach jest mniejsze, więc czas wyszukiwania jest większy, niż w
drzewach bez danych (tylko z odnośnikami). To też nie jest taka
super optymalizacja, to przyspiesza o znikome procenty.


> >> "Przejść" w sensie wyłuskania danych z indeksu klastrowego. Szukał
> >> setnego, musiał (po standardowym przejściu przez poziomy b-drzewa)
> >> pominąć te dane, które są wcześniej.
> > Czyli musiał przejść przez b-drzewo a nie przez dane - to się zgodzę.
> > Przez dane przeskakuje dzięki b-tree.
> 
> Jak pisałem wcześniej - ostatni poziom indeksu klastrowego to de facto 
> dane, a nie jedynie wskazania na nie. Czyli kolejne pozycje tego poziomu 
> są od siebie oddalone o rozmiar wiersza - stąd te skoki i przechodzenie 
> przez dane (analogicznie do wertowanie stron w celu znalezienia 
> Kucharskiego, który powinien być gdzieś dalej po Kowalskim).
Ok, tak samo myślę.


> >> Bo po prostu nie rozumiesz co to jest indeks klastrowy.
> > Pisałem jak ja rozumiem. Jest to indeks, który dodatkowo wymusza
> > fizyczną reorganizację danych w tabeli.
> 
> A to jest "dwa w jednym" (przynajmniej w MSSQL-u).
Tak, ale pamiętaj że to też nie jest taka super rewelacja, bo spada
brenchfactor w drzewach zawierających dane.


> >> Ekspert nie będzie się opierał na intuicji. Sprawdzi na jakich danych
> >> operuje zapytanie. Jeśli okaże się, np. że zamiast varcharów stosowane
> >> są chary, ale i tak wszystkie wartości w nich umieszczane zajmują max
> >> 50% założonej dla nich przestrzeni, to sprawdzi co tak naprawdę ma być
> >> tam przechowywane, dostosuje rozmiar varchara i zamieni chary na
> >> varchary. Doprowadzi to do sytuacji, gdzie wczytanie 1000 rekordów nie
> >> będzie wymagało odczytu tylu stron co poprzednio (bo więcej rekordów
> >> zmieści się na stronie). To jest realne zmniejszenie ilości odczytów z
> >> dysku. To jest także lepsze wykorzystanie bufora na dane.
> > Nie zgodzę się. Taki drobiazg umiem zrobić ja, a nie jestem ekspertem.
> 
> Podałem akurat taki przykład, bo wynikał z kontekstu dyskusji. 
Oj, ale rozmawialiśmy też o ekspertach baz danych.

> Przypadków może być więcej, postaram się skontaktować z liderami 
> warszawskiej PLSSUG, możliwie, że wrzucą ponownie wideo z tej 
> uszkodzonej prezentacji, którą polecałem.
Powiem Ci co by do mnie przemawiało. Przede wszystkim przykłady w
ogromnej ilości i w wielu odmianach. Np. bierzemy bazę która ma
około 8-12 tabel. Włączamy jakiś program. Program wykonuje ileś
operacji wstawiania, usuwania, wyszukiwania. Potem bazę
instalujemy na lepszym dysku i to samo. Potem bazę instalujemy na
kompie z lepszym procesorem i to samo. Potem stopniowo zwiększamy ilość
RAM. Potem wyłączamy bufor systemowy a zostawiamy tylko bufor 
bazy. Potem na odwrót, zostawiamy tylko systemowy, i wylączamy
bufor bazy. Potem nie wiem co... zmieniamy system plików np. na
xfs. Potem nie wiem co... zmieniamy silnki bazy, albo usuwamy testy
więzów integralności... albo zmieniamy opcję optymalizatora...
Co tam dalej... chciałbym zobaczyć jakie bylyby różnice gdyby
każda tabela była na osobnym dysku.

> 
> >>> Ale nie piszemy o przydatności w ogóle varchar, tylko o optymalizacji
> >>> takich drobiazgów jak varchar.
> >>
> >> To wyjaśniłem już wyżej.
> > Moim zdaniem to jest walka o pojedyncze milisekundy, nie wiem czy
> > gra jest warta świeczki.
> 
> Kiedy okazuje się, że trzeba z tego powodu czytać wiele stron (w tym 
> ponownie te, które już odczytano), wówczas nie są to milisekundy. A tak 
> może być przy odpowiednio intensywnym wielodostępie i niewystarczającej 
> na niego pamięci (czasami okazuje się, że wystarczy kilkunastu 
> magazynierów z handheldami kompletujących zamówienia).
Zgoda, ale mam obawę, że relatywnie do całej operacji nadal koszt
wydłuży się o powiedzmy 10%. Jeśli są takie operacje jakie wymieniłeś
powyżej, to ja mam obawy, czy w ogóle rozwiązanie na bazie sql
jest słuszne? Może lepiej bazę trzymać jako taki przydupas do
porządnie zoptymalizowanego programu w C++ albo w Javie? Ja właśnie
ostatnio tak zrobiłem. Baza tylko trzyma dane. Dane są wczytywane
do programu i co jakiś czas uaktualniane. Program będzie instalowany
na wielu maszynach. PHP łączy się z programem i to program robi
zaawansowane złączenia albo wyszukiwania. 

> 
> >>>> Nie mam na myśli podniesienie, mam na myśli obniżenie. Po prostu już na
> >>>> wstępie masz bazę, która wymaga większych zasobów niż to konieczne.
> >>> I z powodu varchar nie podniesiesz istotnie wydajności tamtymi 6 punktami?
> >>> Chciałbym to zobaczyć.
> >>
> >> Być może podniesiesz, ale trzeba brać pod uwagę efekt skali. Może się
> >> okazać, że do obsługi 10 razy większej ilości użytkowników trzeba znowu
> >> rozbudować sprzęt, aby przechowywał on niepotrzebną do niczego
> >> przestrzeń. I nie wystarczy 1 TB RAM.
> > Moim zdaniem, 10 razy więcej użytkowników dzięki optymalizacji vchar, to
> > fikcja. Myślę, że to może dać 1% więcej użytkowników. No chyba że ktoś
> > naprawdę nieudacznie te vchary zrobi. Może dla uściślenia przypomnę.
> > Chodzi o bazę zrobioną przez rozsądną osobe, która w miarę się zna, a
> > potem o ulepszenia wprowadzone przez eksperta. Nie chodzi o bazę
> > zrobioną przez totalnego lamera i potem ulepszoną przez eksperta - bo
> > tak to może faktycznie 10 razy więcej userów...
> 
> 10 razy to rząd wielkości, dla 1000 może się jeszcze nic nie dziać, ale 
> już dla 10 tys...
Nie rozumiem jak to się ma do powyższego.

> 
> 
> >>> A dublowane indeksy, to raczej przedszkole, do tego eksperta chyba nie trzeba?
> >>
> >> Ale nie takie oczywiste dublowane indeksy, ale takie, które niczego nie
> >> wnoszą, bo choć opierają się na innej regule, to i tak optymalizator ich
> >> nie wykorzystuje, bo ma dwa lepsze do tego celu.
> > Tyle że takie indeksy też dużo nie spowalniają. Trochę spada wydajność
> > insertów. Poza tym wywalenie nieużywanych indeksów, to też zadanie
> > dla przeciętniaka, a nie dla eksperta.
> 
> Tylko że Ty patrzysz z punktu widzenia administratora bazy, a nie 
> typowego programisty, który niespecjalnie się przejmuje bazą danych. To 
> dla niego taka czarna skrzynka (jak dla Ciebie indeks), do której po 
> prostu wrzuca dane. I on może nawet przypadkiem założyć taki powielający 
> indeks, ale nigdy nie zajrzy do bazy aby sprawdzić, że jest 
> niepotrzebny. Więc często i gęsto tacy spece od baz danych robią takie 
> proste rzeczy. Ja zresztą takim specem nie jestem, natomiast oglądałem 
> wystąpienia takowych (jakieś 3 lata temu) i to było bardzo pouczające. 
> To był m.in. człowiek, którzy optymalizuje bazy dla Allegro.
Ok, zgodzę się, że spec czasami musi robić prostą, albo nawet krecią
robotę. Ale nie chodziło o to, jaka robota czasami się przytrafia
specowi, ale o to, jaką robotę umie zrobić on, bo nie umie przeciętny
programista.


Spójrz na to tak. Bierzemy 1000 programistów. Każdy napisał przynajmniej
5 aplikacji bazodanychowy i przynajmniej w 2 aplikacjach miał przynajmniej
małe problemy z wydajnością. Po czym sam te problemy rozwiązał. Teraz
sortujemy tych programistów od najlepszych speców od baz danych do
najgorszych. Interesuje mnie, co potrafią zrobić 20 najlepszych z tego
tysiąca, a nie potrafi pozostałe 980 (albo rzadko zdarza się w tych 980 
taki, co by to potrafił).


> >> Klucze naturalne stosuje się rzadko, zazwyczaj tylko wtedy, gdy daje to
> >> uzasadniony zysk wydajnościowy. Ze znanych mi przypadków taki klucz
> >> założono na kodzie towaru, bo kartoteka szła w miliony, a czas
> >> wystawiania dokumentu na podstawie tegoż symbolu był wybitnie istotny
> >> (sprzedaż miała się odbywać szybko, klienci nie lubią czekać).
> > Ciekawe ile zaoszczędzono czasu na tym jednym polu int32 lub int64 w
> > skali całego rekordu. Ciekawe ile by zaoszczędzono, jakby program
> > buforował inserty i wysłał np. w paczkach po 30 insertów. Ciekawe
> > jaki byłby zysk, jakby dziennik dać na specjalnym dysku, no i
> > co by się działo, jakby buforować zapis - zwróć uwagę, że to nadal
> > tanie i łatwe techniki.
> 
> Wydaje mi się, że to było jedyne najbardziej optymalne rozwiązanie - ci 
> dwaj goście, którzy robią ową uszkodzoną prezentację się tym zajmowali, 
> więc (obaj MVP) ja raczej nie mam wątpliwości, że przegapiliby coś lepszego.
Też miałem problem z insertami. Do mojej bazy dużo danych napływa w krótkim
czasie. Długie wstawianie blokowało bazę. Napisałem bufor w zmiennej
PHP. Bufor ma rozmiar np. 1M elementów. Bufor działa jak tablica
skojarzeniowa, więc wyszukiwanie w nim działa bardzo szybko. Przechowuję
jeszcze datę ostatniego dostępu i wywalam najstarsze wpisy. Zanim odpytam
bazę, to odpytuję bufor. Zyskałem gigantyczne przyspieszenie dzięki
takiej prostej technice. Nie pamiętam jakie to było przyspieszenie, ale
rzędu 10-30 razy.

Swoją drogą, nie rozumiem skąd to przyspieszenie. Przecież baza robi
to samo! Moja zmienna też jest serializowana na dysku. Wczytuję ją i 
wyszukuję danych w RAM. Baza też się mieści w buforze RAM. Skąd takie
ogromne różnice w czasie wykonania?



> 
> 
> -- 
> PaSkol (paskol.robi.to)

On Tuesday, February 24, 2015 at 10:18:35 AM UTC+1, Stokrotka wrote:
> Utworzyliśmy bazę o dmyślnej nazwie Tables i w niej
> tabelę o nazwie t3, do której wpisaliśmy kilka rekordów:
> 
> SELECT * from t3;
> 
> id  p31
> ----------
> 1   333
> 2   666
> 3   555
> 4   666
> 5   111
> 
> ...a teraz tworzymy indeksy w pliku o nazwie ind3 dla pola p31:
> CREATE INDEX ind3 ON t3;
> 
> Według manuala instrukcja umożliwiajaca korzystanie z wybranego
> przez programistę indeksu wygląda tak:
> SELECT * from t3 indexed by ind3;
> 
> a tu zonk - dane są w kolejności ich wprowadzania (w MySQL to samo),
> dane nie są posortowane!
> 
> Ale jak dodamy warunek:
> SELECT * from t3 WHERE p31<='666';
> 
> zobaczymy:
> 
> id  p31
> ----------
> 5   111
> 1   333
> 3   555
> 2   666
> 4   666
> 
> Czyli ten - niby optymalizator - dopiero teraz uaktywnił indeksy.
> A wolałbym SAM uaktywniać indeksy bo chcę SAM decydować o kolejności
> sortowania danych w kolumnach. Oczywiście umożliwia mi to jedynie
> ORDER BY ale tak jak zauważyłem ta klauzula tworzy indeksy od nowa
> dla siebie a uważam, że optymalizator powinien nawet dla ORDER BY
> uaktywnić gotowe indeksy a nie je dublować.
> 
> 
> _______
> 
> Bo ty nie rozumiesz co to jest indeks.
> Pierwszym celem indeksu nie jest sortowanie, a szybki dostęp do rekordu.
> Ideks skraca czas dostepu, po to jest.
Ja bym powiedział, że indeks przyspiesza wyszukiwanie, a nie
że skraca czas dostępu. Czas dostępu to raczej cech sprzętu.

> Sortowanie to inna para kaloszy.
> Oczywiście to może mieć związek, ale nie musi.
Często ma ogromny związek, ponieważ wyszukiwanie binarne albo interpolacyjne
działa dobrze na posortowanych danych.

> Gdy dodałeś warunek mniejsze niż, wymusiłeś sortowanie, a raczej tylko jego 
> część,
> bez warunku nie było niezbędne sortowanie.
Gdy dałeś warunek mniejsze niż, to jedynie wymusiłeś odrzucenie danych
większych lub równych. A dzięki indeksom, można szybciej wyszukać
dane, które spełniają dany warunek.


> W bibliotece masz indeks książek.
> One nie leżą od najniższej do najwyższej.
> One też nie leżą od najcieńszej do najgrupszej.
> Jak by tak było, to by były posortowane
> jakimś upożądkowanym sposobem. 
> Ale nie leżą.
Większych głupot w życiu nie słyszalem. To jak wyobrażasz
sobie znalezienie książki jeśli nie są w żaden sposób
uporządkowane?



> One często leżą zgodnie z kolejnością pszyjęcia książki do biblioteki,
> co o niczym nie świadczy, bo nikt nie powiedział,
> że książka pszyjmowana do biblioteki jest nowa,
> może być stara, więc data pszyjęcia nawet nie określa roku wydania,
> nie określa nic poza datą pszyjęcia do biblioteki.
> Jeśli numery będą nadwane kolejno można je traktować jako indeks.
> One nawet nie muszą leżeć po kolei, bo jakaś książka się zniszczyła
> i na jej miejsce na regale wstawisz nowo pszyjętą, ale numer będzie mieć 
> nowy.
> I to właśnie jest indeks.
> Po numerku książki szybko dojdziesz, gdzie ona leży- to jest czas dostępu.
> Gdzieś jest zapisane gdzie leży taki numer.
W żaden sposób nie są uporządkowane, bo uporządkowanie po numerze to
nie jest uporządkowanie ;-)

>Oczywiście sortowanie może być liniowe (wolniejsze) i np. b-tree
>(szybsze).
Zdaje się, że nie ma jeszcze algorytmu sortowania o liniowej złożoności,
ale są o złożoności bardzo bliskiej n ( czyli liniowej).
Najpopularniejsze dla małego zbioru,
bo żadko dostarczane w języku programowania,
więc najczęściej oprogramowywane w praktyce,
jest sortowanie bombelkowe o złożoności n^2.
Programiści tak lubią, ja też,
bo kod jest prosty, a zysk na komplikacji kodu niewielki.

Czym innym też jest sortowanie= szukanie rekordu w nieupożądkowanym zbioże,
a czym innym struktura danyh, często ułatwiająca znalezienie rekurdu.

B-dżewo to sposub upożądkowania- struktura logiczna danyh,
o czasie dostępu do rekordu logarytmicznym, a więc szybszym.
I to zdaje się w jakiejś całkiem dobrej ułamkowej potędze nie pamiętam, już 
jakiej.
Obecnie pewnie są już lepsze struktury, bo o tej uczono mnie, a więc dawno 
temu.
W strukturce tej dane - rekordy podzielone są na strony - struktury podobne 
do wieżhołka w dżewie binarnym, ale w każdym wieżhołku jest wiele rekorduw, 
nie jeden.
Ih ilość - ilość rekorduw w każdym wieżhołku jest ściśle określona i wynosi 
około od k do 2 k , gdzie k- właściwość danego B-dżewa.
Gdy gdzieś tszeba dodać rekord ponadwymiarowy , ten 2k+1, B - dżewo jest 
pszebudowywane.
Ten warunek (ilość rekorduw na stronie od k do 2k, czyli w wieżhołku B-dżewa
ułatwia wyważenie dżewa, to znaczy jego wysokość, z punktu widzenia 
dowolnego liścia.
To jest drugi warunek B - dżewa, to wyważenie, ta identyczna wysokość z 
punktu wiedzenia strony będącej liściem.
Dlatego w B-dżewie czas pesymistyczny jest ściśle okręślony i nie rośnie 
okropnie jak w niejednej innej struktuże danyh, w B-dżewie NIE zależy od 
kolejności wkładania rekorduw do struktury, a w na zwykłym dżewie binarnym, 
stosie albo liście zależy i jest zły - duży.
W dżewie binarnym, w pszypadku pesymistycznym powstaje lista zamiast dżewa
i czas dostępu staje się liniowy, gdy pszeciętnie powinien być zdaje się log 
o podstawie 2.

>Mówię sortowanie bo tak naprawdę chodzi o jak najszybsze
>stworzenie pliku indeksowego,
NIE.


>to jest to osiągnięcie różniące dawne
>.ntx czy .cdx z obecnym .myi w MySQL. Samo szukanie to już pestka
>bo też może używać szybkiego b-tree i w dodatku na już posortowanych 
>danych.

Dalej nie odrużniasz indeksu i sortowania.
Sortowanie nie jest po to by utwozyć indeks, a po to by coś szybko znaleść.


-- 
(tekst bez: ó, ch, rz i -ii)
Ortografia to NAWYK, często nielogiczny, ktury ludzie ociężali umysłowo,
nażucają bezmyślnie następnym pokoleniom. http://ortografia.3-2-1.pl/

On Wednesday, February 25, 2015 at 12:27:14 PM UTC+1, Stokrotka wrote:
> >Oczywiście sortowanie może być liniowe (wolniejsze) i np. b-tree
> >(szybsze).
> Zdaje się, że nie ma jeszcze algorytmu sortowania o liniowej złożoności,
> ale są o złożoności bardzo bliskiej n ( czyli liniowej).
Najlepszą złożonością jaką można uzyskać w sortowaniu
to N*Log(V), gdzie N to ilość danych, a V to ilość
wartości. 

Jeśli w jakimś programie V jest małe i jeśli z góry wiemy że 
nie przekracza jakiegoś małego M, np M=128, to można
zastosować bardzo wydajną implementację takiego sortowania.
Ilość operacji to coś około 2*N+M.

Pozdrawiam

W dniu środa, 25 lutego 2015 12:27:14 UTC+1 użytkownik Stokrotka napisał:
> 
> Dalej nie odrużniasz indeksu i sortowania.
> Sortowanie nie jest po to by utwozyć indeks, a po to by coś szybko znaleść.
> 


PLIK INDEKSOWY ind1 załozony na polu p1 (nazwiska).

indeks czyli:        wartość pola p1
nr rekordu           po sortowaniu
--------------------------------------------
0000 0001            KACPRZAK
0000 0020            KACZMAREK
0000 0300            KACZYŃSKI
0000 0004            KALISZ
0000 0008            KAŁUŻYŃSKA
0000 0006            KAMIŃSKI
0000 2007            KARBOWNIK
0000 8008            KARDAŚ
0000 9909            KAROLAK
0000 1010            KASPRZAK
0000 0011            KASZTELAN            
0000 0012            KEMPA


SLECT * FROM t1 USE INDEX (ind1) WHERE p1>="KAMIŃ";

system bazodanowy przeszukuje plik indeksowy w celu znalezienia "KAMIŃ",

znalazł,

w tabeli t1 skacze do rekordu o numerze 6 i wyświetla wszytkie jego pola (telefon, adres...),

dalej już działa w pętli i pokazuje pola rekordów w t1 o nr:

2007
8008
9909
1010
0011
0012


A więc indeks to tu - numer rekordu, ale w rzeczywistości może to być fizyczne
położenie rekordu na dysku.
Liczy się szybkość znalezienia pierwszego rekordu spełniającego warunek.

Andrzej.

W dniu 2015-02-25 o 14:36, nkab@toya.net.pl pisze:
> W dniu środa, 25 lutego 2015 12:27:14 UTC+1 użytkownik Stokrotka napisał:
>>
>> Dalej nie odrużniasz indeksu i sortowania.
>> Sortowanie nie jest po to by utwozyć indeks, a po to by coś szybko znaleść.
>>
>
>
> PLIK INDEKSOWY ind1 załozony na polu p1 (nazwiska).
>
> indeks czyli:        wartość pola p1
> nr rekordu           po sortowaniu
> --------------------------------------------
> 0000 0001            KACPRZAK
> 0000 0020            KACZMAREK
> 0000 0300            KACZYŃSKI
> 0000 0004            KALISZ
> 0000 0008            KAŁUŻYŃSKA
> 0000 0006            KAMIŃSKI
> 0000 2007            KARBOWNIK
> 0000 8008            KARDAŚ
> 0000 9909            KAROLAK
> 0000 1010            KASPRZAK
> 0000 0011            KASZTELAN
> 0000 0012            KEMPA
>
>
> SLECT * FROM t1 USE INDEX (ind1) WHERE p1>="KAMIŃ";
>
> system bazodanowy przeszukuje plik indeksowy w celu znalezienia "KAMIŃ",
>
> znalazł,
>
> w tabeli t1 skacze do rekordu o numerze 6 i wyświetla wszytkie jego pola (telefon, adres...),
>
> dalej już działa w pętli i pokazuje pola rekordów w t1 o nr:
>
> 2007
> 8008
> 9909
> 1010
> 0011
> 0012
>
>
> A więc indeks to tu - numer rekordu, ale w rzeczywistości może to być fizyczne
> położenie rekordu na dysku.
> Liczy się szybkość znalezienia pierwszego rekordu spełniającego warunek.
>
Tu idzie o przeskok po indeksie. Clippeer mi się przypomina z Browsem: 
Metoda dobra, kursorem się dało lecieć. Z tym, że o błąd tu idze, masz 
unikalne nazwiska, a takich Koalskich, Nowaków było wiele. SELECT * jest 
złym rozwiązaniem, zwraca za dużo i za dużo pamięci zajmuje. Jeśli 
odpytujesz bazę, to pytaj o to co chcesz uzyskać. Masz pewność, że ktoś nie 
zrobił sobie w niej danych binarnych obrazki, filmy). A takie pytania nadal 
się pojawiają. Co się stanie przy select * from tabela przy danych binarnych?
> Andrzej.
>


-- 
Artur
0 weeks 0 days 0 hours 57 minutes 14 seconds and 653 milliseconds.
"pl.comp.bazy-danych"

W dniu środa, 25 lutego 2015 22:12:13 UTC+1 użytkownik artiun napisał:

> Tu idzie o przeskok po indeksie. Clippeer mi się przypomina z Browsem: 
> Metoda dobra, kursorem się dało lecieć. Z tym, że o błąd tu idze, masz 
> unikalne nazwiska, a takich Koalskich, Nowaków było wiele. SELECT * jest 
> złym rozwiązaniem, zwraca za dużo i za dużo pamięci zajmuje. Jeśli 
> odpytujesz bazę, to pytaj o to co chcesz uzyskać.

Przecież to tylko dane dla wyjaśnia dla stokrotki "co ja rozumiem
przez indeks", a nawet jak Kowalskich jest 1000 to select pokaże
te 1000 bo tak chce użytkownik.



> Masz pewność, że ktoś nie 
> zrobił sobie w niej danych binarnych obrazki, filmy). A takie pytania nadal 
> się pojawiają. Co się stanie przy select * from tabela przy danych binarnych?

No z binarnymi jeszcze się nie bawiłem ale podejrzewam,
że klucze mają swoje ograniczenia i obrazków jako danych
binarnych nie da się zaindeksować ale z danymi bajtowymi
zapisanymi znakowo już nie ma problemów (0AC1036A).

Andrzej.