SQLite для клиент-сервера

Я видел пару вопросов о производительности SQLite здесь, в Stackoverflow, но основное внимание уделялось веб-сайтам, и я рассматриваю возможность использования этой БД в сценарии клиент-сервер:

  • Я ожидаю от 1 до 10 клиентов для одного сервера на данный момент, а в будущем может увеличиться до 50 и более.
  • немного больше читает, чем пишет
  • БД будет находиться за серверным процессом (т.е. не использовать прямой доступ к БД через сеть)

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


sqlite performance client-server
person rpg    schedule 24.08.2009    source источник
comment
Поскольку веб-сайт является клиент-серверным приложением, я не понимаю, почему это отличается. Как вы думаете, чем отличается? Почему вы говорите, что клиент-серверное приложение по сути не то же самое, что веб-серверное приложение?   -  person S.Lott    schedule 24.08.2009
comment
По сути, это то же самое, но вопрос масштабируемости SQLite был счетчиком повторений Stackoverflow, поэтому я полагаю, что у него были совершенно другие шаблоны доступа. Еще одним важным отличием будет то, что я могу жестко контролировать весь стек технологий, тогда как в браузере некоторые варианты выбора предопределены за вас.   -  person rpg    schedule 24.08.2009
comment
@rpg: Да, когда у вас есть собственная настройка c/s, у вас больше контроля над всем, как при настройке веб-сайта. На мой взгляд, это говорит о SQLite: когда он масштабируется в настройке веб-сайта, почему бы ему не быть в вашей настройке, где у вас больше контроля? Кроме того, шаблоны доступа, конечно, могут быть проблемой. Многие операции записи (вперемешку с операциями чтения) создают дополнительную нагрузку на механизм БД, поскольку это установка только для чтения. Конечно! Я бы сказал, что это зависит от объема данных, которые вы обычно меняете за один цикл (количество строк, столбцов и таблиц...). Можете ли вы поместить эти записи в одну транзакцию... и так далее?   -  person Juergen    schedule 24.08.2009

Ответы (3)


arrow_upward
14
arrow_downward

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

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

Мне очень нравится SQLite (я даже написал коммерческую утилиту для сравнения баз данных SQLite - SQLite Сравните, но я не думаю, что это отвечает всем требованиям, когда у вас есть сценарии клиент/сервер.

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

person Liron Levi    schedule 25.08.2009
comment
На мой взгляд, у вас могут возникнуть проблемы с тонкой детализацией блокировки только тогда, когда у вас есть несколько серверных процессов, обращающихся к одному файлу БД, или ваши клиенты напрямую обращаются к БД. Когда у вас есть один серверный процесс - как вы можете получить проблемы с блокировкой (хорошо, я должен добавить, что вы не используете потоки...)? - person Juergen; 25.08.2009
comment
На самом деле - у меня есть один сервер, который обращается к базе данных от имени нескольких клиентских процессов. Ну и что? В моем случае каждый клиент представлен рабочим потоком на сервере, и когда у вас есть несколько клиентов, работающих на сервере, у вас также будет несколько потоков, которые одновременно работают с ядром базы данных. Поскольку очень сложно заранее предсказать, как на самом деле будет осуществляться доступ к базе данных (т. е. шаблоны доступа для чтения или записи), я настоятельно рекомендую с самого начала не принимать такого ограничивающего решения (использование SQLite вместо PostgreSQL). - person Liron Levi; 25.08.2009
comment
Есть ли новый дом для вашей утилиты сравнения SQLite? - person Flimzy; 29.08.2012

arrow_upward
3
arrow_downward

Вы не упомянули, какую операционную систему и версии Postgres вы используете. Однако, прежде чем рассмотреть вопрос о смене ядра базы данных, попробуйте выполнить регистрацию и сравнительный анализ вашей текущей базы данных с типичным использованием, а затем оптимизируйте «тяжелые» вопросы. И, может быть, ваша нагрузка на серверную часть делает время запроса БД неуместным? Поскольку SQLite — это файловая СУБД, одновременный доступ из нескольких процессов приведет к снижению производительности при увеличении числа клиентов (отредактировано после комментария)

Может быть полезен следующий вопрос: Насколько масштабируемым является SQLite?

person tomash    schedule 24.08.2009
comment
Снижение производительности произойдет только при прямом параллельном доступе, но, как сказал OP, доступ является косвенным с одним промежуточным серверным процессом ... это может привести к небольшому замедлению, но не к деградации. - person Juergen; 24.08.2009
comment
Правильно, я пропустил один сервер на несколько клиентов. В любом случае, если конструкция БД настолько проста, что ее можно перенести на SQLite (без обработки на стороне БД, триггеров и прочего), я не думаю, что производительность СУБД может быть серьезной проблемой, когда БД разумно индексирована. - person tomash; 24.08.2009
comment
Код еще не писал. Я работаю над списком рисков проекта, и одним из них является масштабируемость. Постгрес не используется, но операционными системами, скорее всего, будут XP, сначала Vista, а затем Linux. - person rpg; 24.08.2009
comment
@rpg: Как я уже сказал в своем ответе, все зависит от фактической нагрузки на БД. Я также хотел бы сказать, что SQLite находится в том же диапазоне производительности, что и PostgreSQL, когда вы можете вычеркнуть одновременный доступ - поэтому с описанной вами настройкой я бы сказал (не зная Postgress), что разница будет небольшой. Зависимость масштабируемости от вашего фактического кода, скорее всего, будет намного выше. Когда вам не нужны все более высокие вещи БД (например, триггеры), я бы порекомендовал SQLite - и 50 пользователей/клиентов для меня не много! - person Juergen; 24.08.2009
comment
@Juergen: может быть, 50 пользователей/клиентов кажутся вам немного, но вы должны учитывать, что каждый из них потенциально может генерировать несколько операторов SQL, которые необходимо выполнять одновременно с запросами, которые выполняются другими клиентами. По моему опыту, блокировка SQLite вызывает серьезные задержки и тайм-ауты графического интерфейса, даже когда одновременно работают ~ 10 пользователей. Это правда, что SQLite — очень быстрая база данных (когда над ней работает только один пользователь). Это также очень легко администрировать. Однако SQLite - это ВСЕ, КРОМЕ масштабируемого решения для базы данных (и я усвоил этот урок на собственном горьком опыте)... - person Liron Levi; 26.08.2009

arrow_upward
1
arrow_downward

Я бы подтвердил ответ С.Лотта.

Я не знаю, как SQLite работает по сравнению с PostgreSQL, так как я не знаю никаких новых измерений, но мой собственный опыт работы с SQLite в довольно похожей среде довольно хорош.

Единственное, что может вызвать проблемы, на мой взгляд, это то, что у вас довольно много записей. Но все зависит от общего числа в секунду, я бы сказал.

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

person Juergen    schedule 24.08.2009