SQLite на виробничому сервері? [зачинено]

Я знаю про SQLite вже давно і знаю, що він швидко палає, але я ніколи не пробував це на виробничому сервері. Мені ніколи не вдалося знайти надійної оцінки того, скільки трафіку він може обробити, перш ніж вийти з ладу.

У когось є якісь цифри чи стаття з цього приводу?

На жаль, я не маю для вас жодних даних про можливості завантаження, але кілька коментарів щодо деяких факторів, що обмежують продуктивність:

• На швидкість SQLite впливає швидкість диска, на якому він знаходиться, і чи багато вкладок / оновлень відбувається (тобто доступ для запису). Блокування запису обмежено швидкістю обертання диска

• Угоди запускаються за замовчуванням, але ви отримаєте більш високу продуктивність , якщо ви почати і здійснити операцію. У мене були дуже швидкі масові вставки під час програмної обробки транзакцій

• Якщо ви, як правило, читаєте лише дані, то ви отримуєте хороші показники з мого досвіду. Отже, SQLite може використовуватися як система кешування для зберігання зчитувань сервера баз даних, окремих віддалених даних або складних запитів.

• Він використовує менше ресурсів, ніж сервер бази даних, тому це може вплинути на продуктивність сайту, оскільки звільнить більше ресурсів для веб-сервера та коду програми

• Якщо вам потрібна кількість одночасних записів, можливо, сервер бази даних (наприклад, MySQL, Postgres) цілком може служити вам краще

Як заявив Devrim , сайт SQLite зазначає, що близько 100 тис. Користувачів на день має бути добре. Система Trac вимагає запису, тому в цьому випадку продуктивність, можливо, буде повільнішою

У мене є кілька моментів, щоб додати до цих хороших відповідей.

Поточна версія SQLite має WAL (Write-Ahead Logging), завдяки чому читання та запис можуть продовжуватися одночасно. Тож традиційного обмеження одного письменника, згаданого в попередніх відповідях, вже не існує. Я ще не бачив WAL у виробництві, тому не можу коментувати, наскільки добре він масштабується.

Використовуючи WAL чи ні, якщо ваша база даних SQLite читається лише (або пакетно оновлюється) і вона вписується в оперативну пам’ять (у вашої ОС є достатня запасна оперативна пам’ять, щоб зберігати її в буферах), вона може дуже добре масштабуватися у виробничому веб-додатку. Я особисто дуже скептично ставився до його продуктивності, масштабованості та надійності, але зараз після дев'яти місяців у виробництві він добре зареєстрував навіть найскладніші частини системи .

Sqlite чудово підходить для вбудовування в додатки, і саме для цього він розроблений, але він, звичайно, не «палає швидко». Я використовую його для декількох власних програм, виключно для зручності наявності лише двох файлів, які можна скопіювати на іншу машину, щоб надати повністю працюючу програму. Тести на MySQL, використовуючи ту саму структуру, індекси тощо, показують, що Sqlite є значно повільнішим, навіть для невеликих баз даних. Я б очікував, що різниця в продуктивності зростатиме в міру збільшення розміру бази даних, хоча я не можу сказати напевно, оскільки я використовував її лише з базами даних менше 100 МБ.

Я думаю, що sqlite є лише швидшим, ніж текстовий / xml-файл (ви можете бути здивовані, якщо ви спробували його). І це не підтримує паралельність, якщо ви хочете створити сайт для інтрамережі, де люди реєструють свої робочі години або використовують квитки на траси, це може слугувати добре. Крім цього, цього слід уникати і замінювати mysql або couchdb.

Веб-сайт sqlite каже, що 100 тис. користувачів на день повинні бути добре, але я дуже сумніваюся в цьому, оскільки простий проект trac сильно застряє при використанні офісу в 10 ppl.

Sqlite не є традиційною програмою DB для клієнтів / серверів. По суті це бібліотека, вбудована в інший додаток. Він призначений для однокористувацьких настільних додатків. Ви абсолютно не хочете намагатися використовувати його як якусь окрему заміну MySQL / PostgreSQL / MS-SQL у середовищі багатокористувача, оскільки вся БД заблокована під час запису. Ви будете мати справу з суперечками навіть про легке навантаження, що знищить продуктивність.