Ежедневно 20-25 миллионов строк, которые будут удалены в полночь для данных за следующие дни. Может ли mySQL обрабатывать 25 миллионов индексированных строк? Что было бы хорошим решением?Лучший бесплатный способ хранения 20 миллионов строк в день?
Из моего опыта, mySQL имеет тенденцию не масштабироваться хорошо. Если у вас должно быть бесплатное решение для этого, я бы высоко рекомендовать postgreSQL.
Также (это может быть или не быть проблемой для вас), но имейте в виду, что если вы имеете дело с такими данными, максимальный размер базы данных mySQL составляет 4 терабайта, если я правильно помню.
Я не думаю, что существует практическое ограничение на максимальное количество строк в mySQL, поэтому, если вы ДОЛЖНЫ использовать mySQL, я думаю, что это сработает для того, что вы хотите сделать, но лично для производственной системы я бы Не рекомендую.
Назад к вашему заявлению с метрикой. Просто говоря, «x не масштабируется хорошо», как правило, используется код «Я не понимаю, как правильно использовать x». –
Насколько я ненавижу MySQL и люблю PostgreSQL, 25 миллионов строк не будут проблемой для него. – kquinn
@Rex M ключевое слово для работы было «из моего опыта», как и в анекдотическом ключе. –
Вы предоставляете очень мало информации о контексте, но иногда не, используя базу данных, а вместо этого бинарный/обычный текстовый файл отлично подходит и может - в зависимости от ваших требований - быть намного более эффективным и обслуживаемым. например, если это данные датчика, хранящие его в двоичном файле, причем каждая запись с известным смещением может быть хорошим решением. Вы говорите, что данные будут удалены каждые 24 часа, кажется, указывают на то, что вам могут не понадобиться некоторые свойства решения реляционной базы данных, такие как ACID, репликация, интегрированное резервное копирование и т. Д., Поэтому, возможно, подход с плоским файлом просто прекрасен?
В качестве общего решения я бы также рекомендовал PostgreSQL, но в зависимости от ваших конкретных потребностей другие решения могут быть лучше/быстрее. Например, если вам не нужно запрашивать данные во время их написания, TokyoCabinet (API/TDB на основе таблицы) может быть более быстрым и легким/надежным.
Я не смотрел на них в MySQL, но это звучит как идеальное приложение для table partitions
Наша база данных MySQL имеет более 300 миллионов строк индексируются, и мы только когда-либо возникают проблемы с комплексом объединений работает немного медленно - большинство из них могут быть оптимизированы.
Обработка строк не была проблемой - ключ к нашей работе был хорошим индексом.
Учитывая, что вы отбрасываете информацию в полночь, я также рассмотрю разбиение на разделы MySQL, которое позволит вам отбросить эту часть таблицы, разрешив на следующий день продолжить вставку, если потребуется.
Это всего лишь данные за 15 дней для собеседника. – duffymo
@duffymo Да, но он убирается каждую ночь в полночь, поэтому с течением времени он не собирается увеличиваться. –
Проблема заключается не в количестве самих строк - это то, что вы делаете с базой данных. Вы делаете только вставки в течение дня, за которым следует какой-то пакетный отчет? Или вы делаете тысячи запросов в секунду на данные? Вставки/обновления/удаления? Если вы нажмете достаточную нагрузку на любую платформу базы данных, вы можете максимизировать ее с помощью одной таблицы и одной строки (наиболее экстремальной). Я использовал MySQL 4.1 w/MyISAM (чуть ли не самое современное из чего-либо) на сайте с 40-тысячной пользовательской таблицей. Я думаю, что это < 5ms запросов. Мы показывали страницы менее чем за 200 мс. Однако у нас было много и много настроек кеширования, поэтому количество запросов было не слишком высоким. И мы делали простые утверждения, такие как SELECT * FROM USER WHERE USER_NAME = 'SMITH'
Можете ли вы прокомментировать свой пример использования?
Если вы используете Windows, вы можете сделать хуже, чем использовать SqlExpress 2008, который должен легко справиться с этой загрузкой, в зависимости от того, сколько индексов вы создаете на нем. До тех пор, пока вы держите < 4GB общий размер db, это не должно быть проблемой.
использование только в качестве индексной базы данных и сохранить его в виде файла подход был бы более эффективным, потому что вы будете удалить в течение 24 часов, и процесс будет быстрее и не обременяют сервер
Иисус! Что делаешь? –
Должен быть индексирование Интернет: D –