Подходит ли SQLite для использования в качестве кэша только для чтения на веб-сервере?

9

В настоящее время я создаю систему ГИС с высоким трафиком, которая использует python на веб-интерфейсе. Система доступна только на 99%. В интересах производительности я рассматриваю возможность использования созданного снаружи кэша предварительно созданной информации GIS, оптимизированной для чтения, и хранения в базе данных SQLite на каждом отдельном веб-сервере. Короче говоря, он будет использоваться в качестве распределенного кеша только для чтения, который не должен перескакивать через сеть. Заднее хранилище OLTP будет postgreSQL, но оно будет обрабатывать менее 1% запросов.

Я рассмотрел использование Redis, но набор данных довольно велик, и поэтому он будет увеличивать стоимость административных расходов и памяти на виртуальных машинах, на которых он находится. Memcache не подходит, поскольку он не может выполнять запросы диапазона.

Я собираюсь ударить с помощью read- concurrency проблем с SQLite?

Является ли это разумным подходом?

  • 1
    Вполне возможно, это первый случай, который я когда-либо видел, где SQLite - самый разумный подход.
  • 0
    Таблицы SQLite периодически обновляются с данными из центральной базы данных postreSQL?
Показать ещё 1 комментарий
Теги:
performance
concurrency

2 ответа

4
Лучший ответ

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

Дополнительная информация здесь:

http://www.sqlite.org/lockingv3.html

Поделиться
  • 0
    Спасибо за публикацию ответа, как только вы его нашли.
-3

если использование - это просто кеш, почему бы вам не использовать что-то вроде http://memcached.org/.

Вы можете найти привязки memcached для python в репозитории pypi.

Другими параметрами являются использование материализованных представлений в postgres, таким образом вы будете держать вещи простыми и иметь все в одном месте.

http://tech.jonathangardner.net/wiki/PostgreSQL/Materialized_Views

Поделиться
  • 5
    Оригинальный плакат гласил: «Memcache не подходит, так как он не может выполнять запросы диапазона».
  • 1
    Memcached не подходит, как указано. Я на самом деле предлагаю материализованные представления, но сгенерированные из серверной части Postgres в файл данных SQLite, который занимает около 4 часов, включая все математические операции. Я бы предпочел не включать его в один движок БД, так как мне придется увеличивать, а не уменьшать, что дорого. Однажды поместите все яйца в одну корзину. Также сетевой трафик, вероятно, будет дорогим (по сравнению с процессором <-> память <-> диск).

Ещё вопросы

Сообщество Overcoder
Наверх
Меню