Использование SQLite в качестве производственной базы данных, плохая идея, но

Question

В настоящее время мы используем postgresql для нашей производственной базы данных в rails, отличной базе данных, но я строю новую версию нашего приложения для SQLite. Действительно, мы не используем расширенные функции postgres, такие как полнотекстовый поиск или PL / SQL. Что касается SQLite, мне нравится идея переноса базы данных, играющей только с одним файлом, ее простая интеграция в сервер и в Rails, и производительность кажется действительно хорошей -> Benchmark

Трафик нашего приложения относительно высок, мы получили примерно 1 200 000 просмотров в день. Итак, мы много читаем из базы данных, но делаем несколько записей.

Что вы думаете об этом? Отзывы от любого, кто использует или пытается (как мы) использовать SQLite как производственную базу данных?

Answer 1

Если вы выполняете много операций чтения и записи, объедините SQLite с неким механизмом кэширования в памяти ( memcache или redis действительно хороши для этого).Это поможет минимизировать количество обращений (чтений) к базе данных.Этот подход помогает в любой среде «много читает-мало-пишет» и помогает избежать недостатков SQLite - в вашем конкретном случае.

Answer 2

SQLite предназначен для встраиваемых систем.Он будет хорошо работать с одним пользователем, но не очень хорошо обрабатывает параллельные запросы.1,2 миллиона просмотров в день, вероятно, означают, что вы получите много последних.

Answer 3

Для выполнения только чтения, я думаю, теоретически это может быть быстрее, чем сервер базы данных вне процесса, потому что вам не нужно сериализовать данные в память или сетевые потоки, все они доступны внутри процесса. На практике это возможно, СУБД может быть быстрее; например, MySQL имеет довольно хорошие функции кэширования запросов и для некоторых запросов это может быть улучшением, потому что все ваши процессы rails будут использовать этот же кеш. С sqllite они не делят кеш.