Один большой MySQL DB или тысяча баз данных SQLite?

Я работаю над веб-инструментом организации. Я не нацелен на тот же рынок, что и замечательный Basecamp, но позвольте сказать, как пользователи и данные взаимодействуют, как одно и то же.

Мне придется иметь дело с пользовательской настройкой, загрузкой файлов и графическими настройками. Для каждой учетной записи есть также fora. И я хотел бы предоставить способ резервного копирования легко каждой учетной записи.

Я думал о том, как создать разумную архитектуру и был обучен использовать прекрасно нормализованные данные в одном (хотя и распределенном при необходимости) DB DB. Недавно мне было интересно: можно ли подумать об использовании одного SQLITE DB для хранения данных для каждой учетной записи и использовать MYSQL только для общего управления веб-сайтом?

Про:

  • резервная копия проста: установите версию, zip, upload.
  • не беспокойтесь, если в каждой учетной записи используются массивные форумы: беспорядок в одном файле для каждого из них.
  • SQLITE быстро осветляется, не требует дорогого времени подключения...
  • Схема таблиц намного проще: не нужно делать различие между учетной записью каждый раз

Против:

  • не знаю, масштабируется ли он
  • не знаю, будет ли поддерживать жесткий диск
  • Не знаю, есть ли способ, чтобы SQLITE не хранился в ОЗУ, поскольку это было бы быстро катастрофой.
  • много директорий и субтитров: будет ли это нормально?
  • проблема обслуживания: обновление сайта в реальном времени означает обновление всех db по одному.
  • проблема с dev: установка dev/pre prod/prod env будет довольно сложной.
  • Commom-данные по-прежнему потребуют использования mysql, поэтому мы закончим с двумя соединениями DB для каждой страницы, arg

Больше, чем плюсы, тем не менее, это заставляет меня задаться вопросом (стиль цепплина).

Что вы скажете?

Ответы

Ответ 1

По существу, на ваш вопрос: какое из вышеперечисленных вариантов лучше для приложения SaaS с несколькими арендаторами?

Несколько небольших баз данных sqlite могут понравиться, но не могут масштабироваться.

Я обращусь к вашим точкам по очереди:

  • резервная копия проста: установите версию, zip, upload.

Что произойдет, если обновление произойдет во время резервного копирования? Сколько времени занимает ваша резервная копия (скажем, тысяча учетных записей с миллионом сообщений)? Сохраняет ли ваша резервная копия базу данных в течение срока действия резервной копии или делает ли она резервное копирование последовательного представления данных или нет? Восстановляет ли резервная копия базы данных во время обновлений в каждом случае? Испытали ли вы эти вещи?

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

  • SQLITE быстро осветляется, не требует дорогого времени подключения...

Ваше предположение, что время соединения MySQL будет "дорого", может быть ложным. У вас есть жесткие данные? Подключение к серверу через локальную сеть на практике не занимает много времени.

  • Схема таблиц намного проще: не нужно делать различие между учетной записью каждый раз

Задумывались ли вы о том, как выполнить миграцию, если вам понадобится изменить схему на этих 1000 небольших баз данных? Какое влияние это окажет на услугу?

Теперь я добавлю некоторые из своих:

  • Масштабируемость. Если вы полагаетесь на локальную файловую систему с семантикой блокировки (как я полагаю, SQLite делает), вы не можете просто добавить больше веб-серверов, так как у них будут свои собственные файловые системы.

Поскольку sqlite не является сетевой системой, вы не можете просто добавить больше веб-серверов. Вам нужно будет либо разбить своих пользователей на несколько серверов, и убедиться, что они только когда-либо попадают на собственный "домашний" сервер (который собирается ввести некоторые проблемы, но может быть жизнеспособным), или выяснить какой-то способ совместного использования базы данных sqlite между серверами, который не будет красивым, и вполне может стереть любые предполагаемые преимущества производительности, которые он когда-либо имел (например, MySQL).

  • Maintainabiliy - Если ваша команда разработчиков делает изменение схемы в базе данных (что не просто возможно, но очень вероятно), ее необходимо будет применить к этим 1000 крошечным базам данных. Успешно. С планом отката.

Я думаю, что масштабирование системы с тысячами крошечных баз данных sqlite не будет масштабироваться. В частности, вы, вероятно, в конечном итоге обнаружите, что вместо 1000 крошечных вы получите 995 крошечных и 5 довольно больших.

Использование выделенного сервера MySQL позволит вам выполнять центральные резервные копии и миграции. Он позволит вам использовать ресурсы в этом поле (то есть ОЗУ) для кэширования наиболее часто используемых частей базы данных, в зависимости от того, в какой учетной записи они находятся.

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

Мои предложения:

  • Рассмотрим приведенные выше пункты, игнорируя их, если вам нравится
  • ИЗМЕРИТЕ эффективность вашего приложения с высокой симулированной нагрузкой на оборудование производственного класса. Убедитесь, что вы используете аппаратное обеспечение для вашего сервера базы данных (например, контроллер с батареей на рейде).
  • Сравните это с реализацией sqlite, если сможете.

Ответ 2

Я дал ему больше мыслей, и я вижу больше проблем:

  • Если я хочу использовать общую область для всего форума, я курил
  • Если я хочу искать через все веб-сайты, это будет апокалиптический
  • Если я хочу статистику, Бог спасет мою душу.

Это была плохая идея.

В любом случае, написание этого на SO заставило меня серьезно подумать об этом. Лучше иметь ясный ум перед началом.

Если однажды, кто-то так же глуп, как и я, надеюсь, что он ударит по странице, чтобы он мог помочь ему пересмотреть

Любите этот сайт (даже если он ASP:-p): самый быстрый способ помочь себе, помогая другим.

Ответ 3

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

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

Ответ 4

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

Если бы я строил систему с нуля, я бы использовал mysql. Поскольку я использую заранее созданную систему, и каждый пользователь имеет свой собственный силос, sqlite работает отлично.

Ответ 5

Вы можете посмотреть на CouchDB для массивного concurrency.