Отдельные базы данных SQLite на пользователя через MySQL?

Question

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

Я думал, что когда пользователи входят в систему и просматривают свои файлы, быстрее будет показать вседанные в одной базе данных SQLite вместо того, чтобы MySQL, просматривали все записи в таблице «file», чтобы извлечь файл одного пользователя по идентификатору.Каждый пользователь может легко иметь более 10000 записей, и изначально будет не менее 400 пользователей.Итак, 400 отдельных баз данных SQLite с 10 000 строк или одна таблица MySQL с 4 миллионами?Учитывая, что все 400 пользователей будут редко (если вообще когда-либо) входить в систему одновременно, кажется неэффективным иметь базу данных для обработки данных для пользователей, которых там нет, даже если они проиндексированы.

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

Мысли?Мнения?Я задумываюсь над этим?

Answer 1

Я делал то же самое с приложением, которое я создал. Каждый пользователь имеет свою собственную базу данных SQLite. Моя причина в том, что я разрешаю пользователю создавать резервные копии своих данных в Dropbox, а также синхронизировать их с соответствующей базой данных SQLite в приложении для iOS (через Dropbox).

Плюсы:
- Пользовательские данные изолированы, и поддержка и просмотр единой базы данных очень просты.
- Данные готовы к отправке в Dropbox в любой момент. Это легко переносимо.

Минусы:
- Как уже говорилось, изменения схемы - это боль. Я должен хранить таблицу в каждой базе данных SQLite под названием «версия» и отслеживать номер версии, который представляет, какова их схема. Изменения схемы включают в себя написание грубых запросов на изменение и перебор всех файлов базы данных, хранящихся на моем сервере.
- Вероятно, сервер несет более тяжелую нагрузку, открывая так много отдельных баз данных. Я подозреваю, что индексированная база данных MySQL будет быстрее.

В целом, это работает, но я на самом деле хочу объединить все данные в одну базу данных MySQL из-за проблем с изменением схемы.

Удачи.

Answer 2

Я подумала, что когда пользователи входят в систему и просматривают свои файлы, будет быстрее просто показать все данные в одной базе данных SQLite, а не MySQL, просматривая все записи в таблице «file», чтобы извлечь одного пользователя файл по идентификатору.

Нет, если вы правильно проиндексировали базу данных MySQL. 4 миллиона записей не должны создавать проблем, если все настроено правильно.

Answer 3

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

400 пользователей тоже нет. Вы, вероятно, вообще не увидите проблем с производительностью на этих уровнях.

Answer 4

Я предполагаю, что это не будет хорошо масштабироваться вообще. Допустим, вы переросли свой текущий сервер и попытаетесь запустить второй сервер базы данных. Какой из них имеет какие идентификаторы пользователей? Репликация master / slave в MySQL означает, что вам не нужно беспокоиться об этой проблеме.

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

Это интересный мысленный эксперимент, но я не думаю, что он сделает то, что вы ищете. Если вы действительно хотите сделать что-то масштабируемое и быстрое, попробуйте взглянуть на MongoDB: http://www.mongodb.org/. Это быстро, гибко и хорошо масштабируется. Кроме того, вы можете хранить список файлов и искать, какой пользователь их загрузил - что может быть полезно, если вы хотите использовать Dropbox, как «только те файлы, которые мы не видели раньше».