Нещодавно я прочитав це запитання про SQLite vs MySQL, і у відповіді було вказано, що SQLite не так масштабується, але офіційний веб - сайт наче це підтверджує .
Наскільки масштабований SQLite і які його верхні межі?
Нещодавно я прочитав це запитання про SQLite vs MySQL, і у відповіді було вказано, що SQLite не так масштабується, але офіційний веб - сайт наче це підтверджує .
Наскільки масштабований SQLite і які його верхні межі?
Відповіді:
Вчора я випустив невеликий сайт *відстежувати представника, який використовував спільну базу даних SQLite для всіх відвідувачів. На жаль, навіть при скромному навантаженні, яке він поклав на мого господаря, він біг досить повільно. Це тому, що вся база даних була заблокована кожного разу, коли хтось переглядав сторінку, оскільки вона містила оновлення / вставки. Я незабаром перейшов на MySQL, і, хоча у мене не було багато часу, щоб перевірити його, це здається набагато масштабнішим, ніж SQLite. Я просто пам’ятаю повільне завантаження сторінок і час від часу отримую помилку з блокованою базою даних при спробі виконання запитів з оболонки в sqlite. Але це означає, що я запускаю ще один сайт із SQLite. Різниця полягає в тому, що сайт є статичним (тобто я єдиний, хто може змінити базу даних), і тому він працює чудово для одночасного читання. Мораль історії:
редагувати : Я щойно зрозумів, що я, можливо, не був справедливим до SQLite - я не індексував жодних стовпців у базі даних SQLite, коли я обслуговував його з веб-сторінки. Це частково спричинило уповільнення, яке я відчував. Однак спостереження за блокуваннями баз даних - якщо у вас особливо обтяжливі оновлення, продуктивність SQLite не буде відповідати MySQL або Postgres.
ще одна редакція: Оскільки я опублікував це майже 3 місяці тому, у мене була можливість уважно вивчити масштабованість SQLite, і за допомогою декількох хитрощів це може бути досить масштабованим. Як я вже згадував у своєму першому редагуванні, індекси баз даних різко скорочують час запитів, але це більше загальне спостереження щодо баз даних, ніж про SQLite. Однак є ще одна хитрість, яку ви можете використовувати для прискорення SQLite: транзакції . Щоразу, коли вам доведеться робити кілька записів у базу даних, вкладайте їх всередину транзакції. Замість того, щоб писати у файл (і блокувати) його щоразу, коли запит на запис видається, запис буде відбуватися лише один раз, коли транзакція завершиться.
Сайт, про який я згадував, який я випустив у першому абзаці, був повернений до SQLite, і він працює досить плавно, коли я налаштував свій код у кількох місцях.
* сайт більше не доступний
Sqlite є масштабованим в плані однокористувацького, у мене багатогігабайтна база даних, яка працює дуже добре, і у мене не було з цим багато проблем.
Але це однокористувальницький, так що це залежить від того , які розширення ви говорите.
У відповідь на коментарі. Зауважте, що ніщо не заважає використовувати базу даних Sqlite в середовищі для багатьох користувачів, але кожна транзакція (фактично, кожен оператор SQL, що модифікує базу даних) робить блокування файлу , що не дозволить іншим користувачам отримати доступ до бази даних на всі .
Отже, якщо в базі даних зроблено багато змін, ви, по суті, дуже швидко зіткнетеся з проблемами масштабування. Якщо, з іншого боку, у вас багато доступу до читання порівняно з доступом до запису, це може бути не так вже й погано.
Але Sqlite буде, звичайно ж функції в середовищі багато користувачів, але він не буде виконувати добре.
SQLite управляє веб-сайтом sqlite.org та іншими, що мають багато трафіку. Вони припускають, що якщо у вас менше 100 тис. Звернень на день, SQLite повинен працювати добре. І це було написано ще до того, як вони поставили функцію "Writeahead Logging".
Якщо ви хочете прискорити роботу з SQLite, виконайте наступне:
Ви можете подивитися на моє відео на YouTube під назвою " Поліпшення продуктивності SQLite за допомогою журналу Writeahead ", де показано, як використовувати журнал запису вперед та продемонструє 5- кратне покращення швидкості запису.
Sqlite - це база даних на робочому столі або в процесі роботи . SQL Server, MySQL, Oracle та їх брати - це сервери .
Настільні бази даних за своєю природою не є хорошим вибором для будь-якої програми, якій потрібно підтримувати паралельний доступ запису до сховища даних. Це включає на деякому рівні більшість створених веб-сайтів. Якщо вам навіть доведеться щось увійти, вам, мабуть, потрібен доступ для запису до БД.
Чи читали ви ці документи SQLite - http://www.sqlite.org/whentouse.html ?
SQLite зазвичай чудово працюватиме як двигун баз даних для веб-сайтів із низьким та середнім рівнем трафіку (тобто 99,9% усіх веб-сайтів). Обсяг веб-трафіку, з яким може працювати SQLite, залежить, звичайно, від того, наскільки сильно веб-сайт використовує свою базу даних. Взагалі кажучи, будь-який веб-сайт, що отримує менше 100 Кт / день, повинен добре працювати з SQLite. Показник 100 К / день - це консервативна оцінка, а не тверда верхня межа. Продемонстровано, що SQLite працює з 10-кратною кількістю трафіку.
Масштабованість SQLite буде сильно залежати від використовуваних даних та їх формату. У мене був складний досвід із надзвичайно довгими таблицями (GPS-записи, один запис в секунду). Досвід показав, що SQLite сповільнюватиметься поетапно, частково через постійне відновлення зростаючих бінарних дерев, що містять індекси (а з індексами, що знаходяться у часі, ви просто знаєте, що дерево буде набагато відновлюватися, але це життєво важливо для вашого пошуки). Отже, зрештою, приблизно в 1 Гб (я дуже відомий) запити стають млявими в моєму випадку. Ваш пробіг буде відрізнятися.
Потрібно пам’ятати, незважаючи на все хвастощі, SQLite НЕ створений для зберігання даних. Існують різні способи використання, які не рекомендуються для SQLite. Чудові люди за SQLite говорять самі:
Ще один спосіб поглянути на SQLite такий: SQLite не призначений для заміни Oracle. Він призначений для заміни fopen ().
І це призводить до головного аргументу (не кількісного, вибачте, але якісного), SQLite не для всіх застосувань, тоді як MySQL може охоплювати багато різноманітних застосувань, навіть якщо не в ідеалі. Наприклад, ви можете мати файли cookie Firefox MySQL для зберігання (замість SQLite), але вам потрібна ця послуга, яка працює весь час. З іншого боку, у вас може бути веб-сайт для транзакцій, який працює на SQLite (як багато людей) замість MySQL, але очікуєте багато простоїв.
ATTACH DATABASEдля створення віртуального з'єднання бази даних з усіма таблицями (однак важко обмежено 62 базами даних).
я думаю, що (у номерах 1) веб-сервер, який обслуговує пошук клієнтів, з’являється в бекенде з одним підключенням до бази даних, чи не так?
Отже, в базі даних немає одночасного доступу, тому можна сказати, що база даних працює в режимі "єдиний користувач". Немає сенсу обговорювати багатокористувацький доступ за таких обставин, тому SQLite працює так само, як і будь-яка інша база даних на базі сервера.
Думай про це так. SQL Lite буде заблокований кожного разу, коли хтось використовує його (SQLite не блокується при читанні). Тож якщо ви розміщуєте веб-сторінку або програму, яка має декількох одночасних користувачів, одночасно ваш користувач може використовувати ваш додаток із SQLLite. Тож правильно виникає проблема масштабування. Якщо це додаток на одну особу, скажімо, Музична бібліотека, де ви зберігаєте сотні назв, рейтингів, інформації, використання, відтворення, час відтворення, то SQL Lite може масштабувати чудово, маючи тисячі записів, якщо не мільйони записів
MySQL, з іншого боку, добре працює для серверних додатків, де люди з усього світу будуть використовувати його одночасно. Він не замикається і має досить великі розміри. Отже, для вашої музичної бібліотеки MySql було б надто вбитим, оскільки бачила б її лише одна людина, ПІДНЯТЬ це спільна музична бібліотека, де тисячі додають або оновлюють її. Тоді MYSQL буде тим, хто буде використовувати.
Тож теоретично, масштаби MySQL краще, ніж Sqllite, тому що він може працювати з неохайними користувачами, але є надмірним для одного користувацького додатка.
Веб-сайт SQLite (частина, на яку ви посилаєтесь) вказує, що його можна використовувати в різних ситуаціях для багатьох користувачів.
Я б сказав, що це може впоратися зовсім небагато. На мій досвід, це завжди було дуже швидко. Звичайно, вам потрібно проіндексувати свої таблиці, і при кодуванні проти них потрібно переконатися, що ви використовуєте парамеризовані запити тощо. В основному те саме, що ви зробили з будь-якою базою даних для підвищення продуктивності.
Можливо, варто перевірити REAL SQL Server - сервер баз даних, побудований на SQLite.