Рекомендации для базы данных в памяти против многопоточных структур данных

Question

TLDR: каковы преимущества и недостатки использования базы данных в памяти по сравнению с блокировками и одновременными структурами данных?

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

У меня нет большого опыта работы с БД, поэтому я спрашиваю других пользователей SO, какой опыт у них был, и каковы плюсы и минусы введения БД в систему?

Answer 1

Что ж, основным недостатком было бы несоответствие между Java и БД. Это большая головная боль, если вам это не нужно. Это также будет намного медленнее для действительно простого доступа. С другой стороны, выгодами будут транзакции и сохранение файловой системы в случае сбоя. Кроме того, в зависимости от ваших потребностей, он позволяет выполнять запросы так, как это может быть сложно сделать с обычной структурой данных Java.

Что-то среднее, я бы взглянул на Neo4j . Это чисто графическая база данных Java. Это означает, что он легко встраивается, обрабатывает параллелизм и транзакции, хорошо масштабируется и не имеет всех проблем несоответствия, которые есть у реляционных БД.

Обновлено Если ваша структура данных достаточно проста - карта списков, карта карт или что-то в этом роде, вы, вероятно, можете избежать проблем с одновременными коллекциями в JDK или с Google Collections , но гораздо дальше, и вы, вероятно, обнаружите, что воссоздаете базу данных в памяти. И если ваши ограничения запросов даже отдаленно сложны, вам придется реализовать все эти возможности самостоятельно. И тогда вам нужно будет убедиться, что они работают одновременно и т. Д. Если это потребует какой-либо серьезной сложности или масштаба (большие наборы данных), я бы точно не бросил ваш собственный, если вы действительно не захотите сделать это.

Если вы решили использовать встроенную БД, существует довольно много вариантов. Возможно, вы захотите начать с рассмотрения того, хотите ли вы идти по пути SQL или NoSQL. Если вы не видите реальных преимуществ использования SQL, я думаю, что это также значительно увеличит сложность вашего приложения. Hibernate - это, вероятно, ваш самый простой маршрут с наименее реальным SQL, но он все еще является головной болью. Я сделал это с Derby без серьезных проблем, но это все еще не так просто. Вы можете попробовать db4o , который является объектной базой данных, которая может быть встроена и не требует отображения. Это хороший обзор. Как я уже говорил ранее, если бы это был я, я бы попробовал Neo4j, но это может быть просто желание играть с новыми блестящими вещами;) Я просто вижу это как быть очень прозрачной библиотекой, которая имеет смысл. Hibernate / SQL и db4o кажутся слишком сильными, чтобы чувствовать себя легковесными.

Answer 2

Вы можете использовать что-то вроде Space4J и получить преимущества как от интерфейса коллекций, так и от базы данных в памяти. При практическом использовании нечто базовое, например, Collection , представляет собой базу данных в памяти без индекса. Список - это база данных в памяти с одним индексом int. Карта представляет собой базу данных в памяти с одним индексом на основе индекса типа T и без параллелизма, если не выполняется синхронизация или реализация java.util.concurrency. *.

Answer 3

Ниже приведено несколько вопросов, которые могут облегчить принятие решения.

• Запросы - вам нужно запросить / перепроектировать / агрегировать ваши данные в различных формах?
• Транзакции - нужно ли вам откатить добавленные данные?
• Постоянство - вам нужно только представить собранные данные или вам также нужно каким-то образом их сохранить?
• Масштабируемость - будут ли ваши данные всегда помещаться в памяти?
• Производительность - как быстро это должно быть?

Answer 4

Однажды я работал над проектом, который использовал Oracle TimesTen. Это было в начале 2006 года, когда только что выпустили Java 5 и классы java.util.concurrent были едва известны. Система, которую мы разработали, имела достаточно большие требования к масштабируемости и пропускной способности (это была одна из основных телекоммуникационных систем для обмена сообщениями SMS / MMS).

Короче говоря, рассуждение о TimesTen было справедливым: «давайте передадим кому-то еще наши проблемы параллелизма / масштабируемости и сосредоточимся на нашей бизнес-сфере», и тогда это имело смысл. Но это было в 2006 году. Не думаю, что такое решение будет принято сегодня.

Сложность параллелизма, как и обработка баз данных в памяти. Чтобы избавиться от проблем с параллелизмом, вам нужно стать экспертом в мире баз данных в памяти. Точная настройка TimesTen для репликации трудна (для этого нам пришлось нанять профессионального консультанта из Oracle). Лицензии не приходят бесплатно. Вам также нужно беспокоиться о дополнительном слое, который не является открытым исходным кодом и / или может быть написан не на том языке, который вы понимаете.

Но действительно трудно судить, не зная вашего опыта, бюджета, временных требований и т. Д. Пройдитесь по магазинам, потратьте некоторое время на изучение приличных систем параллелизма (таких как http://akkasource.org/) ... и дайте нам знать, что вы решили;)

Answer 5

Мне непонятно, почему вы чувствуете, что база данных в памяти не может быть поточно-безопасной.

Почему бы вам не взглянуть на JDO и DataNucleus? У них есть много разных хранилищ данных, где вы можете подключить то, что ваш внутренний поставщик персистентности выполняет во время выполнения в качестве шага настройки. Код вашего приложения зависит от ORM, но ORM может быть подключен к СУБД, DB40, NeoDatis, LDAP и т. Д. Если один сервер не работает для вас, переключитесь на другой.