Один большой MySQL DB или тысяча небольших баз данных SQLite?
Я думаю, что этот вид сортировки может быть достигнут в O (n), с чем-то вроде следующего:
let input = [1, 6, 6, 6, 6, 4, 3, 5, 5, 5, 2, 2]
// build the frequency dictionary (easy task)
let frequencies = input.reduce(into: [:]) { [110][$1] = ([110][$1] ?? 0) + 1 }
// allocate a 2-D array of ints, each item in this array will hold the numbers that
// appear I times in the input array
let frequencyTable: [[Int]] = frequencies.reduce(into: Array(repeating: [Int](), count: input.count)) {
// substracting one as arrays are zero indexed
// we can't get of of bounds here since the maximum frequency is the
// number of elements in the input array
// Also replicating the numbers by their frequency, to have
// the same contents as in the input array
[110][$1.value - 1] += Array(repeating: $1.key, count: $1.value)
}
// lastly, simply flatten the 2-D array to get the output we need
let output = frequencyTable.flatMap { [110] }
print(output)
Пример результата:
[4, 1, 3, 2, 2, 5, 5, 5, 6, 6, 6, 6]
Обратите внимание, что порядок числа с одинаковой частотой могут отличаться в зависимости от того, как работает хэш-функция словаря.
Также мы жертвуем пространство (выделенный 2-D массив) в пользу времени.
Содержание frequencyTable будет выглядеть примерно так (опять-таки порядок 1, 4, 3 может отличаться):
[[4, 3, 1], [2, 2], [5, 5, 5], [6, 6, 6, 6], [], [], [], [], [], [], [], []]
5 ответов
По существу то, что Ваш вопрос: Какое из вышеупомянутого лучше для приложения SaaS коллективной аренды?
Тысяча небольших sqlite баз данных может обратиться, но не может масштабироваться.
Я обращусь к Вашим точкам в свою очередь:
- резервное копирование просто: версия набора, zip, загрузка.
Что происходит, если обновление происходит во время Вашего резервного копирования? Сколько времени делает Ваше резервное взятие (с, говорят, тысяча учетных записей с миллионом сообщений каждый)? Ваше резервное копирование блокирует базу данных на время резервного копирования, или это копирует последовательное представление данных или ни одного? Резервное копирование базы данных, взятое во время обновлений, восстанавливают правильно в каждом случае? Вы протестировали эти вещи?
Я думаю, создавая резервную копию sqlite базы данных, не так легко, как Вы, кажется, думаете из-за параллельной проблемы доступа.
- SQLITE светится быстро, никакое дорогое время соединения...
Ваша импликация, что время Подключения mysql было бы "дорогим", может быть ложью. У Вас есть точные данные? Соединение с сервером по LAN не берет очень долго на практике.
- Схема Table является большим количеством simplier: никакая потребность сделать любое различие между учетной записью каждым времена
Вы думали о том, как Вы сделаете миграцию, если когда-нибудь необходимо изменять схему на этих 1 000 маленьких баз данных? Какое влияние это окажет на сервис?
Я теперь добавлю некоторых моих собственных:
- Масштабируемость: при доверии локальной файловой системе с блокировкой семантики (Поскольку я полагаю, что sqlite делает), Вы не можете просто добавить больше веб-серверов, поскольку у них были бы свои собственные файловые системы.
Поскольку sqlite не является основанной на сети системой, Вы не можете только добавить больше веб-серверов. Вы нуждались бы к любому разделу в своих пользователях через несколько серверов и удостоверились бы, что они только когда-либо поражают свой собственный "домашний" сервер (который собирается представить некоторые проблемы, но может быть жизнеспособным), или выясните некоторый способ совместно использовать sqlite базу данных между серверами, которая не будет симпатичной, и может стереть любые воспринятые преимущества производительности, которые это когда-либо имело (например). MySQL.
- Maintainabiliy - Если Ваша группа разработчиков когда-нибудь внесет изменение схемы в базу данных (который не просто возможен, но и очень вероятно), то она должна будет быть применена к этим 1 000 крошечных баз данных. Успешно. С планом отката.
Я думаю, что масштабирование системы с тысячей крошечных sqlite баз данных не масштабируется. В частности, Вы, вероятно, закончите тем, что нашли, что вместо 1 000 крошечных, Вы заканчиваете с 995 крошечными и 5 довольно большими.
Используя специализированный MySQL сервер позволит Вам выполнить центральные резервные копии и миграции. Это позволит Вам использовать ресурсы на том поле (т.е. RAM) для кэширования наиболее часто используемых частей базы данных, какой бы ни считают, они, оказывается, находятся в.
RAM раньше кэшировала большую базу данных MySQL (например, пул буферов Innodb) может быть снова использован между запросами и совместно используется всеми данными (например, таблицы, строки, столбцы) в нем. sqlite база данных считывает данные с диска каждый раз, когда это необходимо, кроме внутренней части единственная сессия.
Мои предложения:
- Рассмотрите вышеупомянутые вопросы, проигнорируйте их, если Вам нравится
- ИЗМЕРЬТЕ уровень своего приложения с высокой моделируемой нагрузкой на аппаратные средства производственного класса. Удостоверьтесь, что Вы используете производственные аппаратные средства класса для своего сервера базы данных (например, RAID-контроллер с аварийным батарейным питанием)
- Сравните его с sqlite реализацией, если Вы можете.
Я дал ему больше мыслей, и я вижу больше проблем:
- Если я хочу использовать общую зону для всего форума, я являюсь копченым
- Если я захочу искать канавку все веб-сайты, то это будет апокалиптично
- Если я хочу статистику, Бог сохраняют мою душу
Это было плохой идеей.
Так или иначе, при записи этого на ТАК принудительном меня для размышления серьезно об этом. Лучше иметь ясный ум перед запуском.
Если однажды, кто-то так же глуп как я, надежда, он поразит страницу, таким образом, она сможет помочь ему пересмотреть
Любите этот сайт (даже если это - ASP :-p): самый быстрый способ помочь себе, при тихой помощи другим.
SQLite не является точно большей частью масштабируемого решения. Существует причина, почему Вы были обучены использовать красивую, нормализованную базу данных, которая может быть распределена в случае необходимости. Это масштабируемо, и легче поддержать.
Я придерживался бы единственной базы данных MySQL, потому что Вы уже знакомы с той архитектурой, и это - больше, чем, вероятно, лучшее решение для задания.
Вы могли посмотреть на CouchDB для серьезного параллелизма.
Я наткнулся на ваш пост постфактум. Я запускаю хостинговую ферму mediawiki, где у каждой вики есть собственная база данных sqlite. Основная проблема, которую я вижу, заключается в том, что каждая база данных загружается независимо и вызывает некоторые проблемы с памятью. Кроме того, он хорошо подходит для обработки резервных копий и позволяет каждой вики иметь свою собственную базу данных. Поскольку в mediawiki не было настроено несколько вики, это означало, что в mysql каждая вики должна иметь свой собственный набор таблиц со своими собственными префиксами таблиц. Это действительно не сработало, и sqlite был отличной альтернативой.
Если бы я строил систему с нуля, я бы использовал mysql. Поскольку я использую готовую систему, и у каждого пользователя есть свой бункер, sqlite работает нормально.