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

Question

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

В этой ссылке на справку sqlite указано, что:

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

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

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

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

Answer 1

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

Лично, поскольку вы провели тесты, а MySQL быстрееЯ бы просто пошел с MySQL.В будущем это будет более масштабируемым и позволит вам делать больше.

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

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

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

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

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