Увеличение производительности: хранить больше в памяти, меньше в базе данных?

1

Я участвую в проекте, требующем высоких результатов... И мне сказали использовать как можно больше запросов к базе данных, а также использовать больше объектов в JVM-памяти. Правильно.

Итак... Сначала это меня не шокировало, но теперь я сомневаюсь в подходе.

Как я могу узнать, что лучше?

С одной стороны, я бы:

 - static Map <id1, id2>
 - static Map <id2, ObjectX>

Object X
 - id2
 - map <id1, ObjectY>

Object Y
 - id1

Таким образом, эта структура данных поможет мне получить ObjectY от id1. И я также смог бы отправить обратно весь ObjectX, когда это необходимо.

Вы должны знать, что структура заполняется служебным вызовом (A). Затем обновления объектов ObjectY могут выполняться через другую службу (B). Наконец, другая служба может отправить объект ObjectX (C). Что делает три службы, использующие данные.

С другой стороны, я мог бы:

 - db table for ObjectY T1
 - db join table associating id1s and id2s T2
 - db table for Object X T3

Служба A сделает вставку в таблицах. Служба B сделает обновление в таблице T1 Service C сделает соединение между T2 и T1, чтобы получить все объекты ObjectY для ObjectX

По-моему, версия db более гибкая... Я не уверен в производительности, но я бы сказал, что версия db не должна быть медленнее, чем версия "памяти". И, наконец, разве у "версии памяти" не было никаких рисков?

Надеюсь, некоторым из вас кажется очевидным, что я должен выбрать одну версию и почему... Я надеюсь, что это не будет дебатом. Я ищу способы узнать, что быстрее...

Теги:
database
performance

2 ответа

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

Извлечение объекта, хранящегося в памяти, займет порядка сотен наносекунд (меньше, если он был получен в последнее время, и поэтому он находится в кеше). Конечно, эта латентность будет зависеть от вашей платформы, но это приблизительная цифра для сравнения. Извлечение одной и той же информации из базы данных - опять же, это зависит от многих факторов, таких как база данных на одной машине, но она будет иметь порядок миллисекунд, по крайней мере, в десятки тысяч раз медленнее.

Что быстрее - вам нужно быть более конкретным, какие операции вы будете измерять для скорости? Но версия в памяти будет быстрее в большинстве случаев. Версия базы данных дает разные преимущества: постоянство, доступ с разных компьютеров, транзакционное фиксация/откат, но скорость не одна из них, а не сравнение с вычислением в памяти.

Да, в версии с памятью есть риск - в основном, если машина выключена (или по какой-либо причине выходит из строя), повреждение памяти, неотображенное исключение), тогда данные будут потеряны (т.е. Решение в памяти не имеет " persistence "в отличие от базы данных).

Поделиться
2

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

И, хорошо, вы действительно должны получать всевозможные улучшения производительности. Но главная проблема в кэшировании: откуда вы знаете, когда ваша запись в кеше "устарела", т.е. У БД есть контент, который изменился, но ваш кеш не знает об этом?

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

Я думаю, что все компромиссы, которые вы правильно признаете, - это те, которые вам лично нужно взвесить, с дополнительной уверенностью в том, что вы не "пропустили что-то".

Одна последняя мысль - у вас будет достаточно памяти для кэширования всего? Возможно, вам нужно ограничить его, например, до 100 000 объектов, которые запрашиваются. Рассмотрение сторонних инструментов кеширования, таких как EHCache, или Guava может быть полезным:

https://code.google.com/p/guava-libraries/wiki/CachesExplained

Поделиться

Ещё вопросы

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