|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
Нужно хранить очень много xml данных (размер от 3кб до 2мб, avg 40 кб). Максимально до 35 миллиардов записей всего в схеме. В день по 1 млн записей. В схему будет идти постоянный инсерт и редкая выборка по id. Нужно определиться где хранить данные. Удобно было бы в postgres, т.к. остальные данные тоже в нем + понятно как масштабировать/реплицировать/шардировать/секционировать. Но не уверен на счет регрессии в производительности на таком типе данных и таких объемах. Как альтернативу рассматриваю MongoDB+GridFS. Был бы признателен за совет в какую сторону смотреть, может кто-нибудь поделится опытом работы со схожими условиями. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 13:25 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
в нулях запутался) в день 10 млн инсертов, всего 3.6 млрд записей. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 13:42 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
GemorrojВ схему будет идти постоянный инсерт и редкая выборка по id. По-моему, это отличный случай для простой файловой системы. А DFS, например, ещё и шардинг с репликацией обеспечит. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 13:47 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
Gemorroj, - действительно нужно хранить именно XML? - действительно нужно "В схему будет идти постоянный инсерт" или можно инсертить "отдельно"? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 15:00 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
Дедушка, - да, именно xml. это исходные подписанные данные. распаршенные данные из этих xml хранятся отдельно. - имеется ввиду 2 схемы, в 1 инсерт, а во вторую копирование из 1 по расписанию? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 15:19 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
Gemorroj, А в чем проблема с постгресом? Дать достаточно диска для хранения, все равно все данные будут хранится в TOASTе, а поиск будет по ключам. Так что не вижу особых проблем на такой объем. Да и вообще, можно поставить эксперимент с каким-нибудь терабайтником, это будет точнее всего. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 15:30 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
DPH3, К сожалению, нет тестового стенда для полноценного эксперимента. В тестах на 2 млн записей монга и постгрес показывают одинаково хорошие результаты. Но экстраполировать их на 3 млрд было бы неверным. --- "в чем проблема с постгресом?" - нет опыта работы с такими объемами, хочу 7 раз отмерять. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 15:52 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
ну, 100 млн-то можете протестировать? ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 17:44 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
GemorrojВ схему будет идти постоянный инсерт и редкая выборка по id. hadoop+hbase. две колонки, одна id, другая сам xml. может даже разумней по пути во что-то типа avro конвертить ... |
|||
:
Нравится:
Не нравится:
|
|||
30.05.2017, 22:41 |
|
Выбор СУБД для хранения болшого кол-ва XML
|
|||
---|---|---|---|
#18+
Критик, 100 млн тоже без каких-либо видимых проблем. ... |
|||
:
Нравится:
Не нравится:
|
|||
01.06.2017, 11:37 |
|
|
start [/forum/topic.php?fid=48&fpage=5&tid=1856683]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
30ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
45ms |
get tp. blocked users: |
2ms |
others: | 314ms |
total: | 431ms |
0 / 0 |