Хранение сотен миллионов записей

Хранение сотен миллионов записей

Моя компания получит набор данных, состоящий примерно из 200-300 миллионов записей. Исходный материал — csv, его размер около 150 ГБ в несжатом виде. Нам нужно будет выполнить начальную загрузку данных, а затем обновлять примерно 1% записей ежедневно. Мы бы хотели также иметь возможность сохранять историю каждой записи.

В настоящее время мы используем MySQL, и, судя по всему, некоторые люди используют MySQL и PostgreSQL для баз данных такого размера, но я не вижу достаточно подробной информации об их опыте.

Мы определенно могли бы обойтись без нормализации данных, и я могу представить себе распределение информации по множеству серверов. Как насчет MongoDB или какого-то другого нетрадиционного хранилища данных?

Есть ли у кого-нибудь мысли о целесообразности такого рода начинаний? Я ценю любую помощь, которую вы могли бы оказать.

решение1

Мой опыт работы с наборами данных такого размера ограничен MSSQL, но эта СУБД определенно может обрабатывать данные такого размера.

Первое, что меня беспокоит, — это размер данных. 300 миллионов записей по 150 ГБ — это около 500 КБ на строку — и это большая строка. Очень, очень большая строка. Если вы можете нормализовать до 3-й нормальной формы, то это может существенно помочь (при условии, что есть данные, которые можно нормализовать). Если вы не собираетесь нормализовать (и у вас просто одна большая таблица), то движок, поддерживающий ISAM, будет быстрее, чем СУРБД, поэтому MySQL в режиме ISAM — очевидный выбор вместо MSSQL (извините, у меня нет никакого опыта работы с Postgre или Mongo)

При этом MSSQL может справиться с таблицей такого размера, не беспокоясь. Он может разбить данные так, чтобы разные части находились на разных дисках, так что вы можете хранить 1% обновленных данных на быстром диске, а остальные — на более медленном, если бюджет вас смущает. Если ваша СУБД поддерживает это, то это может быть разумным решением.

Просто для справки, однажды я управлял базой данных, в которой было около 200 миллионов строк в одной таблице (но таблица была размером всего 20 ГБ), и с некоторой умной индексацией время запроса все еще измерялось в миллисекундах. Это было нормализовано до 3-й нормальной формы, поэтому было много LOJ для извлечения связанных данных.

решение2

Большинство баз данных могут легко управлять хранением таких больших объемов, это действительно зависит от того, что вы хотите делать с данными после их загрузки. Является ли она транзакционной, поэтому она будет часто запрашиваться и обновляться? Или она больше предназначена для отчетности, когда новая информация поступает каждый день из транзакционной системы?

Связанный контент