|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
Всем привет! Я с big data проекты в глаза не видел, но чисто лично для себя интересно выяснить вот такую архитектуру. Есть машины они генерят кучу данных, к примеру за неделю 100гб текстовых данных, все эти данные классифицируются на определенные метки и записываются в БД (соотношение для этого хранилища insert / select / delete примерно такой 10% / 85% / 5%. ). Далее некии модули получают эти данные и обробатывают складывают в реляционную БД. Для хранения всех жтих файлов хочу выбрать hbase. То есть машина генерит файл , демоны грузят эти данные в hbase и уже приложения работают с hbase. Или просто все это дело в MongoDb настроить replica set и не париться. Кто как бы поступил? Очень интересно. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 19:35 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
alexzfДалее некии модули получают эти данные и обробатывают складывают в реляционную БД.что мешает файлики с диска обрабатывать\складывать (ETL) в реляционную БД? ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 19:44 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
Дедушка, Да это имеет место, но меня не устраивает скорость записи в таблицу, я конечно не пакетной записью пользовался, а простыми инсертами. Конечно можно использовать postgresql а будет ли он справляться с селектами по инстансу размером в 200-300 тб? Скорость выборки тут приоритетней. ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 20:54 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
alexzfКонечно можно использовать postgresql а будет ли он справляться с селектами по инстансу размером в 200-300 тб? вы выше писали о 100Гб в неделю, это всего 5 Тб в год, с которыми справится почти любая СУБД при наличии правильных рук, и потом вдруг откуда-то появляются 200-300 Тб с учетом, что 1Тб enterprise дискового пространства стоит $10 тыс, то вы только за диски отдадите $2-3 млн, а с таким бюджетом на форумах не спрашивают ) ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 21:51 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
alexzf, тут сравнение обычных СУБД для 100 млн строк на обычных машинах, время измеряется считанными минутами http://www.sql.ru/forum/1222372-a/agregaciya-dannyh-100-mln-strok ... |
|||
:
Нравится:
Не нравится:
|
|||
29.06.2017, 21:55 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
Критик, Пардон, все верно 2-3 Тб, опечатался. Я не знаю по ценам по интерпрайс решениям, но ibm блюмиксы по 3тб и 48 ядер есть. Решение ETL и после выборка по этим данным конечно же мне больше нравится чем пользование HDP и в ту степь, но вот я может быть с постгресом что то не так делаю, все пишется медленно. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2017, 11:17 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
alexzf, На локальном сервере в 8 ядер и 32ram ssd ... |
|||
:
Нравится:
Не нравится:
|
|||
30.06.2017, 11:18 |
|
Какое решение выбрать?
|
|||
---|---|---|---|
#18+
alexzf, Учитывая вводную: alexzf Далее некии модули получают эти данные и обробатывают складывают в реляционную БД. и причину выбора: alexzf но меня не устраивает скорость записи в таблицу Стесняюсь спросить... А когда у вас commit при таком раскладе? ... |
|||
:
Нравится:
Не нравится:
|
|||
03.08.2017, 12:17 |
|
|
start [/forum/topic.php?fid=48&fpage=5&tid=1856673]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
36ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
51ms |
get tp. blocked users: |
2ms |
others: | 17ms |
total: | 154ms |
0 / 0 |