Лучший способ хранить небольшие, чередующиеся, общедоступные данные, которые обновляются каждые пару часов?

Question

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

(Упрощено с цельюЭтот форум) Это аукционный сайт, где пять аукционов хранятся в ранге № 1-5, № 1 является текущим аукционом.Остальные четыре просто "на палубе".Через пару часов или после завершения этого аукциона № 2-5 переместятся на # 1-4, и будет выбран новый # 5

. Я использую выделенный сервер ирассматривал просто сохранение данных в сервлете или, возможно, добавление столбца в базе данных в качестве логического значения для каждого аукциона ... как "isFeatured = 1"

Достаточно сказать, что данные читаются примерно 5 раз + большечасто, чем написано, поэтому я склоняюсь к старому доброму SQL.

Answer 1

Когда вы можете получить соответствующие аукционы из БД с помощью простого запроса с ORDER BY и TOP или чего-то подобного, попробуйте это.Если проблем с производительностью не возникает, то KISS и все готово.

В противном случае, если эти 5 аукционов действительны некоторое время, кешируйте их в памяти.Попросите одного аукциона провести эти аукционы и предоставить методы для обновления, например.Возможно, вы хотите использовать кеширующую библиотеку.Обновляйте эти Top5 всякий раз, когда это необходимо, но обслуживайте их напрямую из памяти, не перегружая БД или что-то подобное дорогое.

Answer 2

Вы смотрели на SQLite ?Это позволяет использовать «старый добрый SQL» без каких-либо хлопот по настройке отдельного сервера базы данных.Пока данные не слишком велики (честно говоря, я не проверял ограничения размера, но я просмотрел записи в блогах, в которых упоминается использование SQLite для быстрой и без проблем обработки файлов размером в несколько десятков МБ).), с вами должно быть все в порядке.

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

Answer 3

Какой масштаб вы ищете?Сколько серверов приложений должно иметь доступ к данным?

Я думаю, вы, вероятно, делаете это более сложным, чем оно есть.Просто используйте базу данных, нажмите ACID и переходите на все, что вам нужно для работы.: P