Na jakiej zasadzie działa funkcja indeksowania.
Czy ktoś może mi logicznie wytłumaczyć jak wpływa długość indeksu na szybkość zapytań do bazy danych.
Załóżmy że mamy tabele z 1.mln rekordów.

wyszukujemy w tej tabeli po polu "IP", które ma maksymalnie 15 znaków.

Czy powinniśmy dodać indeks pełne, czy tylko na X znaków, jeśli na X znaków to na ile dokładnie?

Sam dajesz tag SQL a umieszczasz temat w dziale PHP.... przenosze i nagradzam. Masz za dużo postów, by mówić ci gdzie należy umieszczać tematy związane z bazami danych

Niefortunny przykład. Aby IP było optymalnie przechowywane w bazie to nalezy je zapisywać jako INT
http://dev.mysql.com/doc/refman/5.0/en/mis...ction_inet-aton

Musisz mięć adres ip zapisany jak int, żeby indeksować. To co Cię interesuje to funkcje MySQL, które przerabiają adres ip na 32bitowego inta - z adresu ip na inta INET_ATON() i odwrotnie INET_NTOA().

Dokumentacja :

http://dev.mysql.com/doc/refman/5.0/en/mis...ction_inet-aton

Przykład pierwszy lepszy z neta

http://hussfelt.net/blog/sql/store-and-ind...ql-table-faster

Pozdr

ok, wiem już ze trzymanie ip jako varchar jest nie optymalne, ale powróćmy do tematu.
Zakładamy że trzymam ip jako varchar co daje mi nienależenie indeksu i jaką długość powinien mieć indeks.

Po pierwsze adresu IP nie przechowuje się jako INTEGER-a, bo mamy już takie coś jak IPv6, którego wersja liczbowa ma 128-bitów. MySQL nie jest zbyt pomocy w tej kwestii, ale Google i mysql store ipv6 daje sporo rezultatów.

Jeżeli chodzi o indeksy same w sobie, to do poczytania: binary search, binary search, binary search tree, hash function - to da Ci obraz na to, jak działają indeksy.
Jeżeli chodzi o długość indeksu, w tym przypadku powinien on obejmować całą kolumnę.

Napisałem - 32bit int i indeks na to. Jeżeli też uważasz że mamy ipv6 od 95r to musisz faktycznie przekopać googla i znaleźć jakieś hybrydowe rozwiązanie.




Gdzię mamy ? U siebie w domu chyba. ^^ . Podążając tym samym tropem to mamy go już od 95 r. Wszystko dalej pracuje na ipv4.

W '95 to powstała specyfikacja IPv6. Prawie wszystko działa nadal na IPv4 bo jeszcze może, ale w ciągu najbliższych lat (i to wcale nie odległych) pojawią się "publiczne" sieci działające wyłącznie w oparciu o IPv6 - możesz spodziewać się, że dla części użytkowników wszystkie Twoje aplikacje mogą przestać działać.

Mogę się spodziewać o ile jest to dla mnie, a raczej moich aplikacji istotne. Żeby mówić o ipv6, cała globalna sieć musi przejść na ipv6, a u siebie w domu to moge sobie już zrobić sieć opartą na tym protokole. Zanim to nastąpi minie dobrych ileś tam lat.

Mam rozumieć, że wychodzisz z założenia że użytkownik powinien projektować system pod protokoły, które w bliżej nieokreślonej przyszłości będą działały zamiast skupić się na faktycznych protokołach w użyciu, porzucając bardzo dobre mechanizmy dostarczane przez DBMS, które dużo lepiej i szybciej pracują w porównaniu do innych hybrydowych rozwiązań na ipv6, z których i tak teraz nie skorzysta i de facto będzie musiał zrobić na ipv4 tak czy siak.

Wystarczyłoby gdybyś zaznaczył że kiedyś może być to niewystarczające, a nie opowiadać że tego się już nie stosuje i odradzać dobre i sprawdzone sposoby. Poza tym do tego czasu pewnie ta baza będzie jeszcze przerabiana jak i cały system bo technologia idzie do przodu i aplikacje oraz serwery baz danych razem z nią.

Pozdr

Ale kiedy bazy danych bardzo dobrze wspierają i IPv4 i IPv6 - ot, chociażby taki Postgres.
IPv6 to nie jest jakiś tam bajer, który być może kiedyś się gdzieś tam pojawi. To coraz szerzej wprowadzany standard, który wszedł już w fazę globalnych testów, istnieją sieci operujące wyłącznie na nim, a każde dobre oprogramowanie wspiera go. Bo o ile przeciętna aplikacja nie musi się martwić tym co będzie w 2025, o tyle najbliższe 2 - 4 lata to okres na który trzeba patrzyć z nieco większą uwagą, a nie tworzyć buble, które nagle przestaną dla części osób działać z czystego lenistwa programistów. Szczególnie, że z implementacją IPv6 nie ma specjalnego problemu w tego typu aplikacjach.

Nie chce specjalnie chodzić i sprawdzać postgresa, ale rzuciłem okiem na ten Twój link i nie znalazłem niczego o indeksach a jedynie kilka funkcji, które pomagają operować na ip'kach. A pytanie nie dotyczy przechowywania adresu tylko indeksowania. Jeżeli chciałby wchodzić koniecznie w ipv6 musiałby zrobić zarówno ipv4 jak i ipv6, który nie jest wspierany przez DBMS razem to jeszcze spiąć - takie rozwiązanie będzie kulać. Jak ipv6 będzie w standardzie to baza też będzie to wspierać, a teraz wszystko będzie kulawe. Generalnie żeby nie wchodzić w pyskówkę - przytoczę inny przykład. Kiedy Polska będzie w strefie EURO ? No niby w bliżej nieokreślonej przyszłości, o ile ta strefa przetrwa, ale mniejsza o to. To tak jakbyś kazał komuś aby zrobił swój sklep koniecznie w Euro bo Polska przygotowuje się do wejścia w strefe euro i nie będzie już złotówek. Wiedząc przy tym że przejście teraz na euro będzie go dodatkowo kosztowało przeliczaniem euro na złotówki. Może dla Ciebie jest to prawidłowe podejście, jednak na rynku takowej paniki nie ma. Identycznie jest w tym przypadku i tylko o to mi chodziło.

Uprzedzę jeszcze Twój kolejny POST rozmawiamy tu o indeksowaniu ip, nie przechowywaniu. Wówczas nie było nawet dyskusji i niech robi co chce.

Uważam, że warte jest to zaznaczenia, nie koniecznie implementowania, bo chodzi mu o szybkość

Pozdr

1. To co podałem to nie funkcje, a typy kolumn do przechowywania adresów IP / MAC.
2. Adres IPv4 można zapisać przy pomocy IPv6.
3. Indeksowanie jest bezpośrednio połączone z przechowywaniem danych. Mając kolumnę typu INT nie mamy możliwości składowania w niej adresu IPv6, więc mamy (obecnie jeszcze niezbyt poważny) problem.
4. Jak już pisałem, dobre oprogramowanie (system operacyjny, router (o ile nie jest jakiejś wyjątkowo starej daty), przeglądarka czy baza danych) wspiera IPv6, tak więc nic nie będzie działać kulawo.

Twój przykład jest wybitnie nietrafiony bo:
1. To czy Polska w ogóle wejdzie do strefy Euro czy nie nadal jest jednym wielkim znakiem zapytania. Natomiast pojawienie się w publicznym użytku IPv6 jest już przesądzone.
2. Złotówka czy Euro to waluty jakich setki na świecie i każdy sensowny system wspiera dowolną ilość walut. W przypadku protokołu IP mamy do czynienia z jednym, ogólnoświatowym "bytem", który jest stopniowo zamieniany nowym.

Oczywiste - pytanie czy można je indeksować.



Nie bardzo rozumiem.



Trzeba mieć 128 bitów nie 32 taka różnica. Owszem baza tego nie oferuje.





Rozmawiamy o aplikacji webowej, nie o routerach, czy systemach operacyjnych - poza tematem




Niczego nie zrozumiałeś i dalej klepiesz swoje.

Nie rozumiesz prostej rzeczy że albo wszyscy ipv4 albo wszyscy ipv6 ? I na tym polega problem i dlatego nie zostało to jeszcze wprowadzone? Nie będzie sytuacji że niektórzy będą pracować na ipv6, a niektórzy ipv4 - bo jak sobie to wyobrażasz że będziemy mieli 2 internety dla tych ipv4 i ipv6 ?

Powracając do tematu.

Rozchodzi się o to że nie jest to mu w ogóle teraz potrzebne. Jeżeli ipv6 wejdzie to i tak tą tabelą z tymi ip'kami (ipv4) może sobie co najwyżej dupę podetrzeć. Jak będzie ipv6 to i tak potrzebuje nową tabele i nowe indeksy żeby cokolwiek z tym robić.

P.S. - Mysql ma już wstępne gotowe mechanizmy do składowania i indeksowania ipv6, które zostanie dołączone w najbliższych wersjach. Tak więc na ipv6 będzie gotowe.

Pozdr

I między innymi dlatego wypisujesz głupoty typu "Nie rozumiesz prostej rzeczy że albo wszyscy ipv4 albo wszyscy ipv6 ?" czy "Jeżeli ipv6 wejdzie to i tak tą tabelą z tymi ip'kami (ipv4) może sobie co najwyżej dupę podetrzeć.". W obu przypadkach jesteś w błędzie - i to dużym.

Nigdy nie dojdzie sytuacji gdy nagle wszyscy przestaną korzystać z IPv4 i zaczną z IPv6. Będzie pojawiać się coraz to więcej sieci v6, które będą obsługiwać zarówno v6 jak i v4. Bazy danych oferują mechanizmy do składowania, indeksowania i przetwarzania tej struktury danych.

Jak najbardziej w temacie. Aplikacje webowe przetwarzają adresy IP, więc powinny wspierać v6. Wsparcie dla niego wymaga minimalnego wysiłku ze strony programisty (w niektórych środowiskach będzie ono praktycznie zerowe, np. Java + Postgres), a jego aplikacja w 2013 czy 2015 będzie nadal świetnie działać. I nie będzie się musiał bawić w refaktoryzację połowy aplikacji, bo nagle nie da się przetwarzać danych od przykładowo 5% użytkowników.

Dobra widzę, że muszę konkretniej pisać.

Nie ma możliwości aby użytkownicy posiadający stricte ipv4 komunikowali się z tymi co mają stricte ipv6. Zawsze gdzieś musi wystąpić tunelowanie z ipv4 do ipv6 lub odwrotnie. Jeżeli dzisiaj ktoś posiada ipv6 to nie może praktycznie korzystać z internetu, ponieważ nie ma do tego przystosowanego sprzętu czy usług - rochodzi się o serwery dns, usługi takie jak poczta itd. Nikt dzisiaj się nie pcha w ipv6, ponieważ nie daje to nikomu wymiernych korzyści, a wymaga to przebudowy serwerów i nie opowiadaj mi tu bajek zaraz że wszystkie serwery czy te "dobre" są już dawno gotowe tylko komuś gdzieś się nie chce ich przełączyć, albo że będzie to stopniowo wprowadzane. Dlaczego nie ? Internet to nie są tylko serwery, które stoją np. na najnowszych jądrach linuxa, które radzą sobie z ipv6. Tych serwerów jest znikomy procent. A więc każdy usługodawca musi swoje serwy postawić na nowo. Poza tym nie ma dobrych zabezpieczeń do protokołu ipv6, zarówno od warstwy sieciowej kończąc na zabezpieczeniach chociażby deamonów www. Jak cała sieć globalna będzie sobie radzić bardzo dobrze z ipv6 jak i z ipv4 i wszyscy będą sobie ewentualnie tunelować gdy zajdzie potrzeba to będzie to już wprowadzenie ipv6. Przecież nikt nie będzie chciał usługi ipv6, która nie pozwoli w pełni korzystać z internetu. Taka usługa by się w ogóle nie sprzedawała.

Cały internet musi przejść na ipv6 żeby to miało sens. Nie chodzi tu o to że nikt już nie będzie korzystał z ipv4, tylko wszystko będzie przystosowane do obsługi ipv6!

Zanim to nastąpi minie jeszcze spokojnie 10 lat, ponieważ nic się aktualnie w tej sprawie nie dzieje. I takie są rokowania osób, które mają o tym głębsze pojęcie. Możesz tutaj opowiadać ipv6 wejdzie za za rok czy dwa i siać panikę że wszystko przestanie działać (jak w roku 2000) ale tak nie będzie.

Więc dzisiaj kazanie komuś aby koniecznie projektował sobie stronę, czy przerabiał bazę jest przynajmniej dla mnie idiotyczne z czym możesz się nie zgodzić, bo masz do tego demokratyczne prawo. Tym bardziej że rozmawiamy tutaj o tabeli, która ma indeksować ip'ki a nie o wielkich projektach, w których kluczową sprawą jest adres ip, aby w ogóle podejmować dyskusję na ten temat. Jak będzie ipv6 wprowadzone na dobre wówczas sobie zmieni typ kolumny w bazie i tyle. Baza będzie już przystosowana do obsługi ipv6 i wsio. A teraz zamiast zyskać na szybkości (indeksy) będzie miał super bazodanową hybryde do obsługi ipv6 (lub specjalny typ w postgresie), która nie obsługuje indeksów czyli dalej będzie jechał na tym samym i dalej będzie szukać jakiś innych rozwiązań, które przyśpiesza działanie w bazie. Jak wejdzie ipv6 to i tak ją zapewne przerobi na specjalny typ bo pewnie się coś innego pojawi. Zabieg ten jest bardzo prosty i nie wymaga wielkiego wkładu, więc mając na szali dzisiaj twoje kolumny w postgresie a dobre i szybkie, sprawdzone indeksy ipv4 w mysqlu wybieram MySQL'a i IPv4.

Za 10 lat, ba nawet wystarczy i 5 i tak będzie trzeba musowo przerobić stronkę czy aplikację bo będzie 100 lat za murzynami.

Ale w Polsce normalne jest to, że mamy samych specjalistów od wszystkiego więc niech użytkownik sam zdecyduje, poczta w necie i uzna co będzie dla niego lepsze.
Ma dwa stanowiska różne niech wybierze coś dla siebie

Pozdr

1. Dlaczego niby kolumny z adresem v6 miałoby się nie dać indeksować? Dlaczego w MySQL miałby niby nie być w stanie składować v6'ki?
2. Dodanie wsparcia dla v6 teraz to niemal zerowy koszt. Dodanie go za kilka lat, gdy będzie miał kilkanaście czy kilkadziesiąt aplikacji będzie pewnie liczony w dziesiątkach godzin czy tysiącach złotych.
3. IPv6 nie będzie za 5 czy 10 lat. Póle adresów v4 już zostały wyczerpane, pozostają jedynie rezerwy u lokalnych dostarczycieli. Te, w zależności od regionu, mogą się już za 1, 2 lata zacząć wyczerpywać.
4. Po raz kolejny powtarzam, że nigdy nie dojdzie do nagłego przełączenia z v4 na v6. Dwie sieci już istnieją równolegle.

Projektowanie aplikacji z nastawieniem, że za dwa czy trzy lata się będzie ją naprawiać bo z jakiegoś powodu nie chce się jej dobrze zaprojektować to co najmniej dziwne zachowanie.

Swoją drogą, krótkie podsumowanie: http://code.reddit.com/wiki/help/faqs/ipv6

Powiem Ci tak, z tego co piszesz to dalej wnioskuje, że nie zrozumiałeś to co napisałem w poprzednim poście. O MySql i indeksowaniu pisałem wcześniej nie chce mi się non stop pisać to samo. 10 lat to są wypowiedzi ekspertów CISCO na ten temat, jeżeli Ty uważasz lepiej no to muszę się pokłonić przed Tobą, ponieważ jesteś ekspertem sieciowym na tyle wybitnym, że właściwie nie mam się co odzywać. Napisze do Ciebie za 2-3 lata i flaszkę postawisz za to że nie będzie ipv6. Poza tym wiki to faktycznie źródło naukowe. Miło było popisać.

Pozdrawiam

Ta sama firma zachęca również do wspierania IPv6, zgadnij dlaczego. A za 10 lat to pewnie przewidują zniknięcie sieci IPv4-only, chociaż akurat wątpię w tak szybki ich upadek.

A zapewne dlatego że to oni przodują w technologiach sieciowych i wyznaczają standardy. Wiadomo że potrzeba ipv6 - tego nikt nie kwestionuje.

No to teraz nie rozumiem Twojego podejścia. Piszesz, że nikt nie kwestionuje potrzeby IPv6, jednak jeszcze post wczesniej sugerowałeś by sie na niego wypiąć.

Gdzie ja pisałem żeby sie wypinać na ipv6 ? Pisałem że jeszcze tyle do tego brakuje że nie warto. Zresztą można poczytać co pisałem

A nie da rady zrobić indeksy dla obydwu protokołów??Pewnie więcej byłoby z tym pracy ,ale myślę że by się opłacało ,bo w przyszłości mamy problem z głowy.

Więc tak - zależy o jaką bazę danych się rozchodzi. Czy jest to Mysql, Postgresql czy Oracle itp..

Problem polega na tym że adres ipv4 można zapisać jako 32bitowego inta, który się bardzo dobrze indeksuje i można dużo szybciej wyszukać dany rekord. Sama baza danych posiada wbudowane mechanizmy do przekształcania tego inta na adres ipv4. Oczywiście można również dać varchar i też go indeksować, ale jego wydajność będzie zawsze niższa. Przy ipv6 potrzeba 128 bitów, największa jednostka (Mysql) to bigint, który ma 64 bity, także do tego zadania potrzeba dwóch kolumn. Wówczas sprawa się znacznie komplikuje. I naturalnym jest poszukiwanie innego typu kolumny. Jakikolwiek by to nie był typ kolumny będzie zawsze słabszy w porównaniu do 32bitowego inta. Sam ipv6 będzie zawsze słabszy(wolniejszy) nie ważne jaką metodę się zastosuje - bo jest znacznie dłuższy.

Pytanie jest takie - czy ja dzisiaj będę w stanie zaprojektować lepszy system do przeszukiwania i przechowywania ipv6 od konstruktorów baz danych (mimo tego że przez wiele lat będzie on w ogóle nie wykorzystany) ? Oczywiście że nie. To tak samo jakbyś przerabiał auto na gaz. No jakoś leci i pracuje. A jaki będzie wynik jak konstruktor silnika będzie go specjalnie projektował pod gaz. Wynik na pewno będzie lepszy. Problem ipv6 jest odległym tematem. W poprzednich postach próbowałem wytłumaczyć dlaczego tak opornie to idzie, że mamy taki stan rzeczy. Dzisiaj nie powinno się go jeszcze stosować, ponieważ za 10 lat nie ważne jak dobry kawał roboty byś zrobił - twoja stronka czy aplikacja i tak będzie wymagała renowacji. Weźmy na tapetę znowu przykład samochodów. Czy jakikolwiek samochód wyprodukowany 10 lat temu jest lepszy od produkowanych dziś (pomijając sentymenty ) ? No jest to tak oczywiste, że nie wymaga dodatkowych objaśnień.

Dzisiaj bazy danych nie posiadają tych dobrych mechanizmów, a wynika to z tego że ich nie ciśnie po prostu, a jest dużo innych ważnych rzeczy do zrobienia.

Zawsze moszna przechowywać w kolumnie binary-te adresy.Przed zapisem konwertować sttringa do binary,do odczytu konwertować binary do stringa.Możnaby użyć do tego serializacji.Myśle że problemu by z tym nie było, tylko jak z indeksowaniem kolumny binary??

Da się binary jak varbinary i indeksują się również. Tylko podejrzewam że z wydajnością nie jest super. Sposobów na zapis ipv6 jest wiele w necie. Można sobie wybrać jakiś konkretny i sobie zastosować pamiętając o tym że ipv4 też musi tam wleźć i jakoś trzeba to sprawdzić i rozróżnić.

Z wydajnością nie będzie problemów. Właściwie jedyną przewagą indeksu kolumny typu INTEGER jest fakt, że w pewnych przypadkach pobierając dane można wyciągnąć je bezpośrednio z indeksu (nie angażując w ogóle dysku do odczytu danych).

IPv4 można zapisać w formie IPv6 i dosyć łatwo rozpoznać później czy dany IPv6 jest w praktyce v4.

Z tego co wiem tabela musi być w pamięci, jeżeli z dysku nie odczytuje . Nie kumam tego w ogóle. Przybliż mi proszę co miałeś na myśli, bo zaciekawiłeś mnie tym postem;)

W pewnych przypadkach, możliwe jest odczytanie danych bezpośrednio z indeksu, który to jest w pamięci, bez wykorzystywania dysku. By do czegoś takiego doszło muszą być spełnione dwa podstawowe warunki:
1. Indeks musi być równy danym, które reprezentuje, a to w przypadku liczb całkowitych (INT) jest spełnione. Przykładowo: index(0x1455E7) = 0x1455E7 - OK, index("Ala ma kota") = 0x34A35933 - nie OK.
2. Zapytanie musi korzystać wyłącznie z kolumn występujących w indeksie.

I tak zapytanie:

[SQL] pobierz, plaintext 
SELECT ip FROM tbl_name WHERE ip BETWEEN INET_ATON("145.77.42.0") AND INET_ATON("145.77.42.255")
[SQL] pobierz, plaintext 

Ma możliwość pobrania wszystkiego bezpośrednio z indeksu, bez angażowania dysku.

Jak znajdę kiedyś chwilę to wezmę to na warsztat do sprawdzenia;)