![]() |
![]() |
![]()
Post
#1
|
|
Grupa: Moderatorzy Postów: 6 072 Pomógł: 861 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza ![]() |
Witam,
tworzę system, który będzie "bombardowany" dużą liczbą danych. Może przedstawię poglądową strukturę (nazwy poglądowe): produkty: 1x bigint, 1x character varying, 2x tsvector, 1x timestamp produkty_kategorie: 1x bigint, 1x int, 1x smallint zakupy: 1x serial, 2x bigint, 2x smallint, 1x numeric, 1x timestamp Z moich obliczeń wynika, że dziennie do tabeli produkty będzie trafiało ok. 590 000 rekordów, co rocznie daje prawie 220 000 000. Każdemu produktowi odpowiadają średnio 4 rekordy w tabeli produkty_kategorie oraz 3 rekordy w tabeli zakupy. Nawet jeżeli moje obliczenia są zbyt optymistyczne (niech będzie 50% wyliczanych wartości) to i tak baza danych wydaje się być (dla mnie) gigantyczna. Generalnie baza będzie zasilana praktycznie non stop danymi (24h/dobę INSERTY do wspomnianych tabel). Wyszukiwanie będzie odbywało się tylko i wyłącznie po obu polach tsvector z tabeli produkty wraz z polem timestamp z tabeli zakupy. Raz wyszukana informacja zostanie zapisana w tabeli raportów aby następne takie samo żądanie nie wymagało zliczania wszystkiego od nowa (taki swoisty cache). Pytanie zasadnicze: czy PostgreSQL da w tym przypadku radę? Czy macie jakieś doświadczenie przy podobnych liczbach rekordów? Jak to wszystko może działać? Na co zwrócić uwagę? Z góry wielkie dzięki za odpowiedź, pion |
|
|
![]() |
![]()
Post
#2
|
|
Grupa: Zarejestrowani Postów: 57 Pomógł: 9 Dołączył: 12.11.2005 Skąd: ze wnowu?! Ostrzeżenie: (0%) ![]() ![]() |
Na jaka maszyne (ew. ile maszyn?) chcesz to wpakowac? Ile zapytan bedzie szlo w szczycie?
|
|
|
![]()
Post
#3
|
|
Grupa: Zarejestrowani Postów: 2 885 Pomógł: 463 Dołączył: 3.10.2009 Skąd: Wrocław Ostrzeżenie: (0%) ![]() ![]() |
Damy radę (IMG:style_emoticons/default/smile.gif) Może jednak Oracle, bo to już podpada pod zastosowanie przemysłowe ? Swoją drogą - niezłe zlecenie (IMG:style_emoticons/default/smile.gif)
|
|
|
![]()
Post
#4
|
|
Grupa: Moderatorzy Postów: 6 072 Pomógł: 861 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza ![]() |
Widzę, że temat podbity więc się wypowiem. Aktualnie serwis jest w fazie testów, import danych pracuje od ok. połowy grudnia 2009. Liczba rekordów w 3 głównych tabelach waha się od ponad 7 mln rekordów do 25 mln rekordów. Całkowity rozmiar bazy danych to 27GB. PostgreSQL daje radę bez większego problemu. Wyszukiwanie danych (pełnotekstowe + ograniczenie zakresu czasowego) waha się między 8-11 sekund co jest jak najbardziej do przyjęcia. Oczywiście kluczową sprawą są tutaj odpowiednio pozakładane indeksy - bez tego byłaby padaka. Przyznam, że jest to moje pierwsze spotkanie z tak dużą bazą danych i jestem mile zaskoczony wydajnością.
|
|
|
![]()
Post
#5
|
|
Grupa: Zarejestrowani Postów: 57 Pomógł: 9 Dołączył: 12.11.2005 Skąd: ze wnowu?! Ostrzeżenie: (0%) ![]() ![]() |
Jaki jest rozklad zapisow i odczytow? W sensie czego ile?
|
|
|
![]()
Post
#6
|
|
Grupa: Moderatorzy Postów: 6 072 Pomógł: 861 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza ![]() |
Jak pisałem wcześniej: serwis jest w fazie testów więc odczytów nie ma za dużo. W porywach równocześnie na stronie mogą przebywać max 3 osoby testujące. Jeżeli natomiast chodzi o zapisy to jest ich masa. Zdecydowana większość z nich realizowana jest w transakcjach.
Gdy tylko serwis ruszy to pewnie dam go tutaj pod ocenę. |
|
|
![]()
Post
#7
|
|
Grupa: Zarejestrowani Postów: 441 Pomógł: 71 Dołączył: 3.09.2007 Skąd: wrocław Ostrzeżenie: (0%) ![]() ![]() |
A kiedy planowany start ? Możesz coś więcej napisać o tym serwisie ?
|
|
|
![]()
Post
#8
|
|
Grupa: Moderatorzy Postów: 6 072 Pomógł: 861 Dołączył: 10.12.2003 Skąd: Dąbrowa Górnicza ![]() |
Oficjalny start serwisu będzie pewnie za 1-2 tygodnie. Do tego czasu nie mogę nic ujawniać na temat serwisu - mam podpisaną umowę na zachowanie tajemnicy. Generalnie będzie to chyba pierwszy tego typu serwis w Polsce. Może mnogością funkcji nie będzie porażał (podstawowe funkcjonalności) ale za to będzie udostępniał sporą liczbę danych do przedstawiania na wykresach.
|
|
|
![]()
Post
#9
|
|
Grupa: Zarejestrowani Postów: 57 Pomógł: 9 Dołączył: 12.11.2005 Skąd: ze wnowu?! Ostrzeżenie: (0%) ![]() ![]() |
Pytalem o rozklad zapisow i odczytow z powodu indeksow. Indeksy maja taka smutna wlasciwosc, ze moga (znacznie) przyspieszyc wyszukiwanie informacji, ale spowalniaja (znacznie) zapis. Dzieje sie tak, bo baza musi zapisac dane, potem przebudowac index i jego tez zapisac. Skoro masz czas na testy to wywal indeksy i zobacz czy cos sie zmienilo i w ktora strone.
Przygladnij sie tez cache. Nie jestem pewien jak to w psql jest, ale mysql np. cachujac zapytania, zapisuje sobie mape (zoptymalizowanego) zapytania i wyniku, a przy kazdym zapisie do bazy calosc(!) usuwa, co tez zabiera czas. Kiedy nonstop masz goly cache, to tracisz czas na przeszukanie cache czy jest tam wynik, jesli nie to realny odczyt i zapis do cache, z ktorego i tak nic nie przeczytasz, bo zaraz wyleci w kosmos przy nastepnym insercie (lub update, delete). Na zabawe z systemem plikow i takimi tam akcentami to widze, ze juz za pozno... (IMG:style_emoticons/default/winksmiley.jpg) A moze nie? Powiedz na jakich dyskach to siedzi. Jesli masz macierz ze sprzetowym raidem, to moze z 0.5GB ramu i (koniecznie! bez tego nawet nie czytaj dalej:P) bateryjke dla niego zalatw, wylacz barrier i odpal write-cache, oszczedzisz troche ruchu na dyskach i synchronizacji. |
|
|
![]() ![]() |
![]() |
Aktualny czas: 23.08.2025 - 18:40 |