Import do bazy danych z pliku txt - jak to zrobic przy dużej ilości

Witam
proszę o pomoc w imporcie danych do bazy mysql
mam pliki tekstowe z takimi danymi jak poniżej

Imie: Aneta15
Jezyk (pl): Polski
Link: 500123123
Unikalny (kod): zx082i
Imie: Basia1
Jezyk (pl): Polski
Link: 512123123
Unikalny (kod): 08ccE1
Imie: 3Tomek
Jezyk (eng): Angielski
Link: 612123123
Unikalny (kod): r11GH2

chciałbym aby w bazie one wyglądały tak:

Imie | Jezyk (pl) | Link | Unikalny (kod)
Aneta15 | Polski | 500123123 | zx082i
itd.
itd.

mam jeszcze 4 ważne pytania

1. Ile maksymalnie może zajmować jedna baza danych w terabajtach?
2. Ile rekordów maksymalnie można wprowadzić (miliony, miliardy,tryliony... )?
3. Jak duże pliki tekstowe mogę importować do bazy danych a baza wpisze mi je w tabelce tak jak na powyższym przykładzie?
4. Czy taką bazę danych najlepiej zrobić na windowsie w Microsoft SQL Server czy na hostingu? (chodzi mi o szybkość odpowiadania na zapytania)

Proszę o pomoc, dzięki

To mysql czy mssql? Bo to jest dość istotna różnica.

Zanim baza SQL dojdzie do takich rozmiarów, o jakie pytasz, staje się nieoperacyjna, np backup trwa za długo, podmiana dysku jest (z powodów czasowych) niemożliwa itd... Naprzeciwko temu problemowi wychodzą bazy rozproszone (muszą mieć nadmiarowość), ale to zuuuupełnie inna opowieść

generalnie, jak w Ewangelii, nie wiesz o co pytasz

Maker5 napisał(a):

1. Ile maksymalnie może zajmować jedna baza danych w terabajtach?

1 (słownie: jeden) terabajt. Przynajmniej takie są zalecenia dla PostgreSQLa. Powyżej jednego terabajta polecam Cassandrę lub inne bazy oparte na manifeście Dynamo

Tomek Pycia napisał(a):

To mysql czy mssql? Bo to jest dość istotna różnica.

Mysql mam na hostingu gdzie loguje sie przez phpmy admin
mssql jest pod windows, tak?

nie ma różnicy która, najlepiej ta w której szybko mogę zarządzać

AnyKtokolwiek napisał(a):

Zanim baza SQL dojdzie do takich rozmiarów, o jakie pytasz, staje się nieoperacyjna, np backup trwa za długo, podmiana dysku jest (z powodów czasowych) niemożliwa itd... Naprzeciwko temu problemowi wychodzą bazy rozproszone (muszą mieć nadmiarowość), ale to zuuuupełnie inna opowieść

generalnie, jak w Ewangelii, nie wiesz o co pytasz

W zaciszu domowym lub na posiadanym współdzielonym hostingu chcę stworzyć bazę która może zająć 100TB w pierwszym roku użytkowania.
W drugim roku może to już być 1 Petabajt.
Chciałbym później te wszystkie dane przeszukiwać więc jak najlepiej to zrobić przy takiej ilości?

Maker5 napisał(a):

W zaciszu domowym lub na posiadanym współdzielonym hostingu chcę stworzyć bazę która może zająć 100TB w pierwszym roku użytkowania.
W drugim roku może to już być 1 Petabajt.
Chciałbym później te wszystkie dane przeszukiwać więc jak najlepiej to zrobić przy takiej ilości?

Nie ogarniesz tego znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej bo Cię Joiny zabiją. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów, ale raczej nie do jednego Petabajta. Przy tej ilości danych trzeba stawiać klaster np Cassandry lub innego dedykowanego do tego NoSQLa

Kamil Żabiński napisał(a):

Maker5 napisał(a):

W zaciszu domowym lub na posiadanym współdzielonym hostingu chcę stworzyć bazę która może zająć 100TB w pierwszym roku użytkowania.
W drugim roku może to już być 1 Petabajt.
Chciałbym później te wszystkie dane przeszukiwać więc jak najlepiej to zrobić przy takiej ilości?

Nie ogarniesz tego znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej bo Cię Joiny zabiją. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów, ale raczej nie do jednego Petabajta. Przy tej ilości danych trzeba stawiać klaster np Cassandry lub innego dedykowanego do tego NoSQLa

Czy mógłbyś mi to napisać po polsku?
dziękuję

Maker5 napisał(a):

Kamil Żabiński napisał(a):

Maker5 napisał(a):

W zaciszu domowym lub na posiadanym współdzielonym hostingu chcę stworzyć bazę która może zająć 100TB w pierwszym roku użytkowania.
W drugim roku może to już być 1 Petabajt.
Chciałbym później te wszystkie dane przeszukiwać więc jak najlepiej to zrobić przy takiej ilości?

Nie ogarniesz tego znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej bo Cię Joiny zabiją. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów, ale raczej nie do jednego Petabajta. Przy tej ilości danych trzeba stawiać klaster np Cassandry lub innego dedykowanego do tego NoSQLa

Czy mógłbyś mi to napisać po polsku?
dziękuję

Długa droga przed Tobą skoro nie wiesz co to normalizacja i denormalizacja danych. Czego dokładnie nie rozumiesz? I tak konkluzja jest taka że ani MySQL, ani SQL Server, ani nawet brzydki Oracle tego nie uciągnie. Ale na razie się tym nie przejmuj. Zbuduj prototyp/MVP na MySQLu czy lepiej PostgreSQLu i jak dojdziesz do jednego terabajta to będziesz się przejmować

Ja bym się przede wszystkim zapytał: co to mają być za dane? Jak mają być przeszukiwane? Przy takich wielkościach trzeba szyć rozwiązania na miarę. O ile to są rzeczywiste wielkości, bo stan wiedzy pytającego (orz tytuł tematu) nie napawa mnie pewnością, że to nie jest problem XY.

kq napisał(a):

Ja bym się przede wszystkim zapytał: co to mają być za dane? Jak mają być przeszukiwane? Przy takich wielkościach trzeba szyć rozwiązania na miarę. O ile to są rzeczywiste wielkości, bo stan wiedzy pytającego (orz tytuł tematu) nie napawa mnie pewnością, że to nie jest problem XY.

Przykład: Posiadam plik, który zawiera milion rekordów zapisanych w notatniku.
Wielkość tego pliku to 200 megabajtów.
To są dane bez znaków specjalnych, same cyfry i numery nic specjalnego jak widziales w przykladzie
malo tego, nawet nie ma polskich znakow!
Docelowo bede mial dwie bazy gdzie z czasem pojawi sie koniecznosc przeszukiwania bazy 1 pod kątem rekordów zapytań czy rekordów wcześniej wprowadzonych do drugiej.

Jest różnica między 200mb a 100tb - ok 500 000x. Gigabajtową bazę to sobie postawisz i na przeciętnym laptopie, i nie będzie wielkiej różnicy czy to MySQL, PostreSQL, MSSQL, a nawet SQLite - dużo większa różnica będzie czy poprawnie utworzysz indeksy itd.

kq napisał(a):

Jest różnica między 200mb a 100tb - ok 500 000x. Gigabajtową bazę to sobie postawisz i na przeciętnym laptopie, i nie będzie wielkiej różnicy czy to MySQL, PostreSQL, MSSQL, a nawet SQLite - dużo większa różnica będzie czy poprawnie utworzysz indeksy itd.

Dlatego tak jak napisałem. 200 MB to jest plik wyjściowy z milionem rekordów.
Kolejne pliki bedą takie same.
Jak obliczyłem całość w 1 roku zajmuje te 100 TB.
Jak to ogarnąć a później tym zarządzać?
co mógłbyś zaproponować?

Przede wszystkim, zoptymalizowałbym proces, który wykonujesz. Skala bazy, którą opisujesz jest prównywalna do gigantów - może nie Facebooka czy Amazona, ale już tuż tuż¹. Co takiego robisz, że potrzebujesz tak ogromnych rozwiązań? Wracamy do "szycia rozwiązania na miarę". Jak często chcesz przeszukiwać te dane? Jak będzie wyglądało zapytanie? Jak często dokładasz? 100TB na rok to wychodzi 200MB/minutę - czy na pewno potrzebujesz dane od początku historii? Czy te dane mają być w jakiś sposób weryfikowane (np. unikalność indeksów)?

Ogółem, jeśli rzeczywiście potrzebujesz takich wielkości, to zatrudnij do tego konkretnego architekta, któremu (pod NDA?) opiszesz dokładnie swój przypadek użycia, i który zaproponuje i wdroży odpowiednie rozwiązanie dla Twoich potrzeb.

¹ hiperbola

Maker5 napisał(a):

kq napisał(a):

Jest różnica między 200mb a 100tb - ok 500 000x. Gigabajtową bazę to sobie postawisz i na przeciętnym laptopie, i nie będzie wielkiej różnicy czy to MySQL, PostreSQL, MSSQL, a nawet SQLite - dużo większa różnica będzie czy poprawnie utworzysz indeksy itd.

Dlatego tak jak napisałem. 200 MB to jest plik wyjściowy z milionem rekordów.
Kolejne pliki bedą takie same.
Jak obliczyłem całość w 1 roku zajmuje te 100 TB.
Jak to ogarnąć a później tym zarządzać?
co mógłbyś zaproponować?

A będziesz te dane zmieniał czy tylko dokladał kolejne pliki. Może jakiś hadoop w modelu hostowanym. Najlepiej było by to zlecić jakiemuś specjaliście. Sam tego nie ogarniesz

Maker5 napisał(a):

Witam
proszę o pomoc w imporcie danych do bazy mysql
mam pliki tekstowe z takimi danymi jak poniżej

Imie: Aneta15
Jezyk (pl): Polski
Link: 500123123
Unikalny (kod): zx082i
Imie: Basia1
Jezyk (pl): Polski
Link: 512123123
Unikalny (kod): 08ccE1
Imie: 3Tomek
Jezyk (eng): Angielski
Link: 612123123
Unikalny (kod): r11GH2

chciałbym aby w bazie one wyglądały tak:

Imie | Jezyk (pl) | Link | Unikalny (kod)
Aneta15 | Polski | 500123123 | zx082i
itd.
itd.

Języki możesz umieścić w słowniku, zaś w danych trzymać referencję do słownika -> oszczędność na storage. Zamiast kodowania literek, będziesz miał kodowanie np. integera na "mniejszym" typie danych.

Imiona pewnie też można umieścić w słowniku i zamiast wartości Aneta15 trzymać referencję do "Profilu użytkownika" -> kolejna oszczędność na storage

mam jeszcze 4 ważne pytania

1. Ile maksymalnie może zajmować jedna baza danych w terabajtach?

Tyle ile się uzbiera. Różnie silniki mają różne mechnizmy radzenia sobie z ogromem danych.

2. Ile rekordów maksymalnie można wprowadzić (miliony, miliardy,tryliony... )?

j.w.

3. Jak duże pliki tekstowe mogę importować do bazy danych a baza wpisze mi je w tabelce tak jak na powyższym przykładzie?

j.w.

4. Czy taką bazę danych najlepiej zrobić na windowsie w Microsoft SQL Server czy na hostingu? (chodzi mi o szybkość odpowiadania na zapytania)

Szybkość odpowiedzi zależy od zasobów sprzętowych, natężenia ruchu, rodzaju zapytań etc.

Twoje pytanie można porównać do: "Jak szybko na poczcie obsługuje się interesanta?" To zależy...

Gdzie chcesz te 100 TB trzymać? Potrzebujesz backupu bazy? Ile czasu może trwać odtworzenie bazy z backupu (ile czasu usługa może być niedostępna)?
Masz jakąś retencję danych przewidzianą?

Przypuśćmy, że faktycznie te 100TB będziesz miał i chcesz, żeby to działało... Jest taki Postgres na sterydach. Nazywa się Greenplum i ma następujące charakterystyki:

Te 100TB można na jednej partycji upchnąć :-)

kq napisał(a):

Przede wszystkim, zoptymalizowałbym proces, który wykonujesz. Skala bazy, którą opisujesz jest prównywalna do gigantów - może nie Facebooka czy Amazona, ale już tuż tuż. Co takiego robisz, że potrzebujesz tak ogromnych rozwiązań? Wracamy do "szycia rozwiązania na miarę". Jak często chcesz przeszukiwać te dane? Jak będzie wyglądało zapytanie? Jak często dokładasz? 100TB na rok to wychodzi 200MB/minutę - czy na pewno potrzebujesz dane od początku historii? Czy te dane mają być w jakiś sposób weryfikowane (np. unikalność indeksów)?

Ogółem, jeśli rzeczywiście potrzebujesz takich wielkości, to zatrudnij do tego konkretnego architekta, któremu (pod NDA?) opiszesz dokładnie swój przypadek użycia, i który zaproponuje i wdroży odpowiednie rozwiązanie dla Twoich potrzeb.

Masz u mnie dużego plusa za analityczny umysł :) że też wyliczyłeś prędkość 200 MB na minutę :)
Dokładnie! Wychodzi dokładnie 200 MB na minutę.
To co robię to gromadzenie określonych danych w celu późniejszego ich przeszukiwania.
Dane chciałbym przeszukiwać tak często jak można np. 10 razy dziennie lub częściej. Zależy też to od tego ile trwałoby takie przeszukiwanie bazy po wprowadzeniu zapytania.
Zapytaniem byłby określony zestaw znaków w celu znalezienia w bazie podobnych lub tych samych znaków (rekordów).
Póki co zoptymalizowałem dane ale mimo to i tak wychodzi około 110 MB do 120 MB na minutę na plik.
Jest jeszcze ostatnia opcja, np. wprowadzenie do bazy tylko części danych z plików tekstowych a całość plików archiwizować z kompresją na dyskach.
W takim scenariuszu zawsze można byłoby się odwołać do archiwum jeśli w bazie po wprowadzeniu zapytania zostanie odnalezione to co nas interesuje.
Tak będę potrzebował całej historii przy każdym zapytaniu chyba, że właśnie można byłoby to ułatwić poprzez jakieś indeksowanie lub skompresować
archiwalne dane kodując je w jakiś inny sposób?

Tomek Pycia napisał(a):

Maker5 napisał(a):

kq napisał(a):

Jest różnica między 200mb a 100tb - ok 500 000x. Gigabajtową bazę to sobie postawisz i na przeciętnym laptopie, i nie będzie wielkiej różnicy czy to MySQL, PostreSQL, MSSQL, a nawet SQLite - dużo większa różnica będzie czy poprawnie utworzysz indeksy itd.

Dlatego tak jak napisałem. 200 MB to jest plik wyjściowy z milionem rekordów.
Kolejne pliki bedą takie same.
Jak obliczyłem całość w 1 roku zajmuje te 100 TB.
Jak to ogarnąć a później tym zarządzać?
co mógłbyś zaproponować?

A będziesz te dane zmieniał czy tylko dokladał kolejne pliki. Może jakiś hadoop w modelu hostowanym. Najlepiej było by to zlecić jakiemuś specjaliście. Sam tego nie ogarniesz

tylko dokladał, żadnych zmian

Maker5 napisał(a):

Tomek Pycia napisał(a):

Maker5 napisał(a):

kq napisał(a):

Jest różnica między 200mb a 100tb - ok 500 000x. Gigabajtową bazę to sobie postawisz i na przeciętnym laptopie, i nie będzie wielkiej różnicy czy to MySQL, PostreSQL, MSSQL, a nawet SQLite - dużo większa różnica będzie czy poprawnie utworzysz indeksy itd.

Dlatego tak jak napisałem. 200 MB to jest plik wyjściowy z milionem rekordów.
Kolejne pliki bedą takie same.
Jak obliczyłem całość w 1 roku zajmuje te 100 TB.
Jak to ogarnąć a później tym zarządzać?
co mógłbyś zaproponować?

A będziesz te dane zmieniał czy tylko dokladał kolejne pliki. Może jakiś hadoop w modelu hostowanym. Najlepiej było by to zlecić jakiemuś specjaliście. Sam tego nie ogarniesz

tylko dokladał, żadnych zmian

No to ja bym szukał czegoś hostowanego w jakieś chmurze i co daje dobra analityke. Poszukaj co daje AWS azure lub Google i tam bym szukał pod to rozwiązania.

Ciekawe, jak kolega planuje na to budżet

AnyKtokolwiek napisał(a):

Ciekawe, jak kolega planuje na to budżet

Przede wszystkim rozsądny!
Robiąc to lokalnie potrzebowałbym 10 dysków po 10TB co daje oczywiście 100TB i 10 tys. złotych.
Do tego stacja robocza, która zajmowałaby się zapisem danych i późniejszymi zapytaniami.
Coś pominąłem?

Przy 10 dyskach RAID6 to absolutne minimum, więc realnie to będzie 12-13 dysków po 10TB. 20 przy RAID1.

Maker5 napisał(a):

Kamil Żabiński napisał(a):

Maker5 napisał(a):

W zaciszu domowym lub na posiadanym współdzielonym hostingu chcę stworzyć bazę która może zająć 100TB w pierwszym roku użytkowania.
W drugim roku może to już być 1 Petabajt.
Chciałbym później te wszystkie dane przeszukiwać więc jak najlepiej to zrobić przy takiej ilości?

Nie ogarniesz tego znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej bo Cię Joiny zabiją. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów, ale raczej nie do jednego Petabajta. Przy tej ilości danych trzeba stawiać klaster np Cassandry lub innego dedykowanego do tego NoSQLa

Czy mógłbyś mi to napisać po polsku?

1. Nie ogarniesz
   Nie zrobisz tego sam z takim zasobem wiedzy.
2. znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej
   To taki naukowy bełkot specjalistów od relacyjnych baz danych, potocznie zwanymi bazami SQLowymi. Nie martw się tym co wypisuje, ponieważ idę o zakład że sam @Kamil Żabiński nigdy takiej bazy nie zrobił (no chyba że na studiach) :P
   Trzecia postać normalna (określana jako 3NF) de-facto określa zapis danych bez powtórzeń, co jednoznacznie wymusza używanie łączenia danych (zwanych złączeniami), aby uzyskać syntetyczny widok danych.
   Innymi słowy, 3NF ma się nijak do tego jak dane będą przechowywane w bazie relacyjnej i w Twoich plikach, ale można je prezentować tak jak w Twoich plikach. Tylko, że będzie to wymagało dodatkowego łączenia danych do prezentacji, a to z kolei generuje dodatkowy narzut dla silnika bazo-danowego. I to Kamil miał na myśli pisząc "bo Cię Joiny zabiją".
3. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów
   Te postacie normalne to taka konwencja, a nie ograniczenie czy narzut technologiczny.
   A więc da się z tego zrezygnować (tylko jakiś profesor od relacyjnych baz danych może paść na zawał, jak zobaczy model takiej bazy) w celu uproszczenia modelu przechowywania danych w celu ulżenia bazie danych podczas ich przetwarzania (np. wyszukiwania). To często stosowana technika, kiedy zależy nam na wydajności i mamy dokładnie zdefiniowany model przetwarzania danych; a więc wiemy o co będziemy pytać bazę danych, jaki wolumen danych baza ma przetwarzać i jakich wyników oczekujemy.
   Tylko to de-facto półśrodek i trzeba z tym uważać, kiedy założenia się zmienią może to być nieużywalne.
4. klaster np Cassandry
   Tu sobie w wiki doczytaj czym jest Apache Cassandra.
5. innego dedykowanego do tego NoSQLa
   No i wchodzimy w grząski grunt baz NoSQLowych; to takie super wydajne bazy danych dedykowane do przetwarzania ogromnej ilości danych w "czasie rzeczywistym". NoSQL, co nie wszyscy wiedzą, nie oznacza NIE-SQL a "not only SQL".
   Tak czy siak, dla podanego przez Ciebie wolumenu danych wydaje się to naturalnym wyborem.
   Rozwiązań tego typu jest od metra i możesz sobie je wynająć w chmurce, nie musisz tego utrzymywać na własnym serwerze.
   Jeśli nie będziesz generował ogromnego ruchu w postaci ilości zapytań, to osadzenie takiego rozwiązania w chmurze (AWS, Azure, GooleCloud) może się okazać wysoce efektywnie ekonomicznie.

Masz jeszcze inne podejście, tj. ETL i DataWarehouse (np. Pentaho, Apache Druid).
NoSQL to raczej tzw. BigData, ale podany scenariusz nie wpisuje się w rasowe BigData, co nie znaczy że się nie nada.

dziękuję

A proszę bardzo.

PS.
MS SQL działa zarówno pod Windows, Linux i w chmurze.

wloochacz napisał(a):

Maker5 napisał(a):

Kamil Żabiński napisał(a):

Maker5 napisał(a):

W zaciszu domowym lub na posiadanym współdzielonym hostingu chcę stworzyć bazę która może zająć 100TB w pierwszym roku użytkowania.
W drugim roku może to już być 1 Petabajt.
Chciałbym później te wszystkie dane przeszukiwać więc jak najlepiej to zrobić przy takiej ilości?

Nie ogarniesz tego znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej bo Cię Joiny zabiją. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów, ale raczej nie do jednego Petabajta. Przy tej ilości danych trzeba stawiać klaster np Cassandry lub innego dedykowanego do tego NoSQLa

Czy mógłbyś mi to napisać po polsku?

1. Nie ogarniesz
   Nie zrobisz tego sam z takim zasobem wiedzy.
2. znormalizowaną relacyjną bazą danych w trzeciej postaci normalnej
   To taki naukowy bełkot specjalistów od relacyjnych baz danych, potocznie zwanymi bazami SQLowymi. Nie martw się tym co wypisuje, ponieważ idę o zakład że sam @Kamil Żabiński nigdy takiej bazy nie zrobił (no chyba że na studiach) :P
   Trzecia postać normalna (określana jako 3NF) de-facto określa zapis danych bez powtórzeń, co jednoznacznie wymusza używanie łączenia danych (zwanych złączeniami), aby uzyskać syntetyczny widok danych.
   Innymi słowy, 3NF ma się nijak do tego jak dane będą przechowywane w bazie relacyjnej i w Twoich plikach, ale można je prezentować tak jak w Twoich plikach. Tylko, że będzie to wymagało dodatkowego łączenia danych do prezentacji, a to z kolei generuje dodatkowy narzut dla silnika bazo-danowego. I to Kamil miał na myśli pisząc "bo Cię Joiny zabiją".
3. Trochę da się przesunąć granicę denormalizując dane i rezygnując z joinów
   Te postacie normalne to taka konwencja, a nie ograniczenie czy narzut technologiczny.
   A więc da się z tego zrezygnować (tylko jakiś profesor od relacyjnych baz danych może paść na zawał, jak zobaczy model takiej bazy) w celu uproszczenia modelu przechowywania danych w celu ulżenia bazie danych podczas ich przetwarzania (np. wyszukiwania). To często stosowana technika, kiedy zależy nam na wydajności i mamy dokładnie zdefiniowany model przetwarzania danych; a więc wiemy o co będziemy pytać bazę danych, jaki wolumen danych baza ma przetwarzać i jakich wyników oczekujemy.
   Tylko to de-facto półśrodek i trzeba z tym uważać, kiedy założenia się zmienią może to być nieużywalne.
4. klaster np Cassandry
   Tu sobie w wiki doczytaj czym jest Apache Cassandra.
5. innego dedykowanego do tego NoSQLa
   No i wchodzimy w grząski grunt baz NoSQLowych; to takie super wydajne bazy danych dedykowane do przetwarzania ogromnej ilości danych w "czasie rzeczywistym". NoSQL, co nie wszyscy wiedzą, nie oznacza NIE-SQL a "not only SQL".
   Tak czy siak, dla podanego przez Ciebie wolumenu danych wydaje się to naturalnym wyborem.
   Rozwiązań tego typu jest od metra i możesz sobie je wynająć w chmurce, nie musisz tego utrzymywać na własnym serwerze.
   Jeśli nie będziesz generował ogromnego ruchu w postaci ilości zapytań, to osadzenie takiego rozwiązania w chmurze (AWS, Azure, GooleCloud) może się okazać wysoce efektywnie ekonomicznie.

Masz jeszcze inne podejście, tj. ETL i DataWarehouse (np. Pentaho, Apache Druid).
NoSQL to raczej tzw. BigData, ale podany scenariusz nie wpisuje się w rasowe BigData, co nie znaczy że się nie nada.

dziękuję

A proszę bardzo.

PS.
MS SQL działa zarówno pod Windows, Linux i w chmurze.

Bardzo Ci dziękuję za wyczerpującą odpowiedź, teraz o wiele więcej rozumiem.
Jak myślisz przy moich potrzebach 100TB rocznie jakie to mogłyby być koszty miesięczne w takim Azure czy Google?
Zakładając, że będę wysyłał zapytania od kilkunastu razy dziennie do kilkudziesięciu razy dziennie.

kq napisał(a):

Przy 10 dyskach RAID6 to absolutne minimum, więc realnie to będzie 12-13 dysków po 10TB. 20 przy RAID1.

I dla takich dysków trzeba policzyć ile IO na sekundę taka "domowa macierz" wygeneruje.

Jeśli to dyski obrotowe (przy budżecie 10k to nawet nie zakładałbym, że SSD ;) ), to powiedzmy, że 10 dysków x 200 IOPS (dyski z wyższej półki => 15k RPM SAS,) x 4kb (IO size) => ~8 MB/s transferu z takiej "macierzy". I teraz leci full scan na tabeli 100TB (bo kolega op zapomniał indeksu) => ~13 milionów sekund => ~150 dni :)

Dla dysków SSD może być szybciej, ale drożej (większa ilość mniejszych dysków).

yarel napisał(a):

kq napisał(a):

Przy 10 dyskach RAID6 to absolutne minimum, więc realnie to będzie 12-13 dysków po 10TB. 20 przy RAID1.

I dla takich dysków trzeba policzyć ile IO na sekundę taka "domowa macierz" wygeneruje.

Jeśli to dyski obrotowe (przy budżecie 10k to nawet nie zakładałbym, że SSD ;) ), to powiedzmy, że 10 dysków x 200 IOPS (dyski z wyższej półki => 15k RPM SAS,) x 4kb (IO size) => ~8 MB/s transferu z takiej "macierzy". I teraz leci full scan na tabeli 100TB (bo kolega op zapomniał indeksu) => ~13 milionów sekund => ~150 dni :)

Dla dysków SSD może być szybciej, ale drożej (większa ilość mniejszych dysków).

No właśnie to jest realny problem do rozwiązania.
Jak przeszukać te 100TB w czasie kilku minut??
Ze względu na cenę wchodzą w grę tylko HDD.
Czy szybkość procesora w stacji roboczej miałaby tu jakiekolwiek znaczenie w sensie czy wpłynęłaby na szybkość przeszukiwania
jeśli porównalibyśmy np. procesor 12 rdzeniowy vs 24 rdzenie?
Podobnie z Ramem, czy zwiększenie ramu np. do 256 GB mogłoby pomóc?

Maker5 napisał(a):

...

No właśnie to jest realny problem do rozwiązania.
Jak przeszukać te 100TB w czasie kilku minut??
...

A co to znaczy przeszukać? Jakiego rodzaju zapytania byłby realizowane na takich danych? Jeśli za każdym razem trzeba wszystko czytać, to RAM i CPU nie pomogą... Chyba, że RAM będziesz miał tyle co storage ;)

Maker5 napisał(a):

Bardzo Ci dziękuję za wyczerpującą odpowiedź, teraz o wiele więcej rozumiem.

Z torii baz danych zapewne.
Jednak z punktu widzenia rozwiązania Twojego problemu, szczerze uważam że jesteś w czarnej du...ie.

Jak myślisz przy moich potrzebach 100TB rocznie jakie to mogłyby być koszty miesięczne w takim Azure czy Google?

Ja myślę, ze się źle do tego zabierasz i najprawdopodobniej to Ci w ogóle do niczego niepotrzebne.
Te 100 TB, czy piksopierdolety.
Pewnie liczysz zapotrzebowanie na dane z czystego strumienia danych wejściowych i taki chcesz przetwarzać
A to błąd.

A poza tym, sorry wykaż odrobinę zaangażowania.
Azure czy Google posiada odpowiednie kalkulatory do oszacowania kosztów.
Skorzystaj z nich.

Zakładając, że będę wysyłał zapytania od kilkunastu razy dziennie do kilkudziesięciu razy dziennie.

Zakładam że zabierasz się do tego od tyłu strony.
Poważnie :)

yarel napisał(a):

Maker5 napisał(a):

...

No właśnie to jest realny problem do rozwiązania.
Jak przeszukać te 100TB w czasie kilku minut??
...

A co to znaczy przeszukać? Jakiego rodzaju zapytania byłby realizowane na takich danych? Jeśli za każdym razem trzeba wszystko czytać, to RAM i CPU nie pomogą... Chyba, że RAM będziesz miał tyle co storage ;)

Ostatnio bookmacherka jest modna, a kwerendy są tajne, przecież to źródło dochodu. Albo coś w tym stylu.

wloochacz napisał(a):

Maker5 napisał(a):

Bardzo Ci dziękuję za wyczerpującą odpowiedź, teraz o wiele więcej rozumiem.

Z torii baz danych zapewne.
Jedynak z punktu widzenia rozwiązania Twojego problemu, szczerze uważam że jesteś w czarnej du...ie.

...

Zakładam że zabierasz się do tego od tyłu strony.
Poważnie :)

100% się zgadzam