Лучший бесплатный способ хранить 20 миллионов строк в день?

Question

Ежедневно 20-25 миллионов строк, которые будут удалены в полночь для данных следующих дней. Может ли mySQL обработать 25 миллионов проиндексированных строк? Какое еще одно хорошее решение?

Answer 1

Вы предоставляете очень мало информации о контексте, но иногда не , используя базу данных, и вместо этого бинарный / простой текстовый файл вполне подходит и может - в зависимости от ваших требований - быть гораздо более эффективным и обслуживаемым , например, если данные датчика хранятся в двоичном файле с каждой записью с известным смещением, это может быть хорошим решением. Вы говорите, что данные будут удаляться каждые 24 часа, и это указывает на то, что вам могут не понадобиться некоторые свойства решения для реляционной базы данных, такие как ACID, репликация, интегрированное резервное копирование и т. Д., Так что, возможно, подход с плоскими файлами вполне подойдет?

Answer 2

Наша база данных MySQL имеет более 300 миллионов проиндексированных строк, и мы только когда-либо сталкиваемся с проблемами, когда сложные объединения выполняются немного медленно, хотя большинство из них можно оптимизировать.

Обработка строк не была проблемой - ключом к нашей производительности были хорошие показатели.

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

Answer 3

Проблема не в количестве строк, а в том, что вы делаете с базой данных. Вы делаете только вставки в течение дня, после чего следует какой-то пакетный отчет? Или вы делаете тысячи запросов в секунду к данным? Вставки / обновления / удаления? Если вы загружаете достаточно нагрузки на любой платформе базы данных, вы можете максимизировать ее с помощью одной таблицы и одной строки (доводя ее до крайности). Я использовал MySQL 4.1 с MyISAM (едва ли не самым современным) на сайте с пользовательской таблицей в 40 миллионов строк. Я думаю, он сделал <5ms запросов. Мы рендерили страницы менее чем за 200 мс. Тем не менее, у нас было много и много настроек кэширования, поэтому количество запросов было не слишком большим. И мы делали простые заявления, такие как SELECT * FROM USER WHERE USER_NAME = 'SMITH' </p>

Можете ли вы прокомментировать ваш вариант использования?

Answer 4

Если вы используете Windows, вы можете сделать хуже, чем использовать SqlExpress 2008, который должен легко справиться с этой нагрузкой, в зависимости от того, сколько индексов вы создаете для нее. Пока вы сохраняете <4 ГБ общего размера, это не должно быть проблемой. </p>

Answer 5

использование только в качестве индексной базы данных и сохранение ее в виде файлового подхода будет более эффективным, поскольку вы удалите его в течение 24 часов, и процесс будет быстрее и не обременит ваш сервер

Answer 6

Я не рассматривал их в MySQL, но это звучит как идеальное приложение для разделов таблицы

Answer 7

В качестве общего решения я бы также порекомендовал PostgreSQL, но в зависимости от ваших конкретных потребностей другие решения могут быть лучше / быстрее. Например, если вам не нужно запрашивать данные во время их записи, TokyoCabinet (API / TDB на основе таблицы) может быть быстрее и более легким / надежным.

Answer 8

Исходя из моего опыта, MySQL имеет тенденцию не очень хорошо масштабироваться. Если вам нужно бесплатное решение, я бы очень рекомендовал postgreSQL .

Также (это может или не может быть проблемой для вас), но имейте в виду, что если вы имеете дело с таким большим количеством данных, максимальный размер базы данных mySQL составляет 4 терабайта, если я правильно помню.

Я не думаю, что есть практическое ограничение на максимальное количество строк в mySQL, поэтому, если вы ДОЛЖНЫ использовать mySQL, я думаю, это будет работать для того, что вы хотите сделать, но лично для производственной системы я бы не стал не рекомендую.