sqlite или mysql для больших наборов данных

Я работаю с большими наборами данных (10 миллионов записей, иногда 100 миллионов) и хочу использовать программу базы данных, которая хорошо связывается с R. Я пытаюсь решить между mysql и sqlite. Данные статичны, но есть много запросов, которые мне нужно сделать.

в этой ссылка на SQLite help, в нем говорится, что:

" при размере страницы по умолчанию 1024 байта размер базы данных SQLite ограничен 2 терабайтами (241 байт). И даже если это может обрабатывать большие базы данных, SQLite хранит всю базу данных в одном файле диска, и многие файловые системы ограничивают максимальный размер файлов чем-то меньшим, чем это. Поэтому, если вы рассматриваете базы данных такого масштаба, вам следует рассмотреть возможность использования компонента клиент/сервер database engine, который распространяет свое содержимое по нескольким дисковым файлам и, возможно, по нескольким томам."

Я не уверен, что это означает. Когда я экспериментировал с mysql и sqlite, кажется, что mysql быстрее, но я не построил очень строгие тесты скорости. Мне интересно, является ли mysql лучшим выбором для меня, чем sqlite из-за размера моего набора данных. Описание выше, кажется, предполагает, что это может быть так, но мои данные не где-то рядом с 2TB.

было обсуждение stackoverflow это коснулось этого и ссылалось на ту же информационную страницу sqlite, но это не совсем решило этот вопрос.

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

6
mysql r sqlite

4 ответов

компонент SQLite database engine хранит всю базу данных в одном файле. Это может быть не очень эффективно для невероятно больших файлов (предел SQLite составляет 2 ТБ, как вы нашли в справке). Кроме того, SQLite ограничен одним пользователем за раз. Если ваше приложение основано на интернете или может оказаться многопоточным (например,AsyncTask на Android), mysql, вероятно,путь.

лично, так как вы сделали тесты и mysql быстрее, я бы просто пошел с mysql. Это будет больше масштабируемость в будущем и позволит вам сделать больше.

6

Я не уверен, что это означает. Когда я экспериментировал с mysql и sqlite, кажется, что mysql быстрее, но я не построил очень строгие тесты скорости.

короткая короткая версия:

  1. Если ваше приложение должно поместиться на телефоне или другой встроенной системе, используйте SQLite. Для этого он и был создан.

  2. Если ваше приложение может понадобиться больше, чем один параллельное соединение, не используйте SQLite. Используйте PostgreSQL, MySQL с InnoDB и т. д.

4

Кажется, что (по крайней мере, в R), что SQLite является удивительным для ad hoc анализ. С RSQLite или sqldf пакеты очень легко загружать данные и начинать работу. Но для данных, которые вы будете использовать снова и снова, мне кажется, что MySQL (или SQL Server) - это путь, потому что он предлагает гораздо больше возможностей с точки зрения изменения вашей базы данных (например, добавление или изменение ключей).

3

SQL, если вы в основном используете это как веб-службу. SQLite, если вы хотите, чтобы он мог функционировать в автономном режиме.

SQLite обычно намного быстрее, так как большинство (или Все) данных/индексов будут кэшироваться в памяти. Однако в случае SQLite. Если данные разделены на несколько таблиц или даже несколько файлов базы данных SQLite, из моего опыта до сих пор. Для даже миллионов записей (у меня еще есть 100 миллионов), это намного эффективнее, чем SQL (компенсировать время задержки и т. д.). Однако это происходит, когда записи разбиваются на разные таблицы, а запросы специфичны для таких таблиц (dun запрашивает все таблицы).

примером может служить база данных элементов, используемая в простой игре. Хотя это может звучать не так много, UID будет выпущен даже для вариаций. Таким образом, генератор вскоре быстро работает более чем на миллион наборов "статистики" с вариациями. Однако это было в основном связано с тем, что каждые 1000 наборов записей были разделены между различными таблицами. (как мы в основном тяните записи через свой UID). Хотя эффективность расщепления не была должным образом измерена. Мы получали запросы, которые были легко в 10 раз быстрее, чем SQL (в основном из-за задержки сети).

забавно, однако, мы в конечном итоге сократили базу данных до нескольких 1000 записей, имея пункт [pre-fix] / [suf-fix] определить вариации. (Как и Диабло, только то, что он был скрыт). Что в конце дня оказалось намного быстрее.

на боковой ноте, хотя, мой случай был в основном из-за того, что запросы выстраиваются один за другим (ожидая одного перед ним). Если, однако, вы можете сделать несколько подключений / запросов к серверу одновременно. Снижение производительности в SQL более чем компенсируется с клиентской стороны. Предполагая, что эти запросы не ветвятся / взаимодействуют друг с другом (например. если получен результат запроса это, остальное что)

1