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

Question

После прочтения this question и предлагаемого link explaining when is more appropriate to use SQLite vs another DB мне все еще не ясно, одна простая вещь, и я надеюсь, что кто-то сможет ее прояснить.

Они говорят:

Ситуация Где SQLite хорошо работают

Сайты

SQLite обычно будет работать велик, как ядро ​​базы данных для низких и средних сайтов трафика .. .

...

Ситуации Где Еще RDBMS мая Работа Лучше

Client/Server Приложения ...

Если у вас есть много клиентских программ с доступом к общей базы данных по сети ...

не является websi te также приложение клиент/сервер?

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

Просто чтобы это было просто: в конце концов, можно ли, например, использовать этот SQLite для сайта электронной коммерции или онлайн-каталога или сайта CMS с примерно 1000 продуктами/страницами?

Answer 1

SQLite может разрешать несколько клиентских чтений, но только один клиент пишет. См.: https://www.sqlite.org/faq.html

Клиент/сервер - это когда несколько клиентов выполняют одновременную запись в базу данных, такую ​​как запись заказа, когда несколько пользователей одновременно вставляют и обновляют информацию или многопользовательский блог, где есть несколько одновременных редакторов.

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

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

Обратите внимание, что количество продуктов/страниц не является отличным способом определения требований к MySQL по SQLite, а это число одновременных пользователей, и в какой момент их параллельное поведение испытывает медленность из-за ожидания блокировок Чисто.

Answer 2

Веб-сайт не обязательно является приложением клиентского сервера в контексте использования.

Я думаю, когда они говорят на веб-сайте, они означают, что веб-приложение будет напрямую управлять базой данных. То есть файл базы данных будет жить на веб-сайте и не будет доступен с помощью каких-либо других средств. (Единственная точка доступа, просто)

Напротив, клиентское/серверное приложение может иметь веб-сайт, доступ к хранилищу данных , а также другой веб-сайт, клиент SOAP или даже смарт-клиент. В этом контексте у вас есть несколько клиентов для доступа к одной базе данных (серверу). Именно здесь веб-сайт станет (еще одним) клиентом.

---

Другой аспект, который следует учитывать при построении двух, представляет собой процентное соотношение записей по сравнению с чтением. Я думаю, что SQLite будет работать успешно, когда будет мало записи, по сравнению с количеством чтений. SQLite, я понимаю, не очень хорошо работает в сценарии множественной записи. Он предназначен для одного (нескольких?) Процессов, чтобы манипулировать им.

Answer 3

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

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

В приложении базы данных клиент-сервер, однако, нескольким пользователям может потребоваться, чтобы соединения открывались в течение более длительных периодов времени, а также может потребоваться выполнение транзакций. Это гораздо менее проблематично для больших систем РСУБД, поскольку блокировка может выполняться более мелкозернистым способом.

Answer 4

В основном я использую только SQLite для встроенных приложений. (iOS, Android). Для более крупных, более сложных веб-сайтов (например, для описания) я бы использовал что-то вроде mySQL.