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

Question

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

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

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

Профи:

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

Минусы:

• не знаю, масштабируемо ли это
• не знаю, будет ли работать жесткий диск
• не знаю, есть ли способ сохранить SQLITE в оперативной памяти, поскольку это быстро приведет к катастрофе
• много dir и subdirs: это будет хорошо?
• проблема с обслуживанием: обновление живого сайта означает обновление всех БД по одному
• проблема с dev: настройка dev / pre prod / prod env будет довольно сложной
• Для данных commom по-прежнему потребуется использование mysql, поэтому в конце мы должны завершить соединениями по 2 БД для каждой страницы, arg

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

Что вы говорите?

Answer 1

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

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

Я поочередно рассмотрю ваши вопросы:

• Резервное копирование - это просто: установить версию, zip, загрузить.

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

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

• SQLITE быстро светит, нет дорогого времени соединения ...

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

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

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

---

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

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

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

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

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

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

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

---

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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