Ответ 1

При условии, что я не использовал Datomic в производстве, подумал, что дам вам ответ.

Преимущества

• Запросы Datalog являются мощными (более чем нерекурсивными SQL) и очень выразительными.
• Запросы могут быть записаны с помощью структур данных Clojure, и это НЕ слабый DSL, как многие библиотеки SQL, которые позволяют вам запрашивать структуры данных.
• Это неизменно, поэтому вы получаете преимущества, которые неизменность дает вам в Clojure/на других языках а. Это также позволяет хранить, сохраняя структуры, все прошлые факты в вашей базе данных - это ОЧЕНЬ полезно для аудита и более

Недостатки

• Это может быть медленным, поскольку Datalog будет только медленнее, чем эквивалентный SQL (при условии, что может быть записан эквивалентный оператор SQL).
• Если вы пишете LOT, вам может понадобиться беспокоиться о том, что один трансактор будет перегружен. В большинстве случаев это маловероятно, но о чем-то думать (вы можете сделать какой-то осколок, но, возможно, и сбережете себя, но это не БД для хранения данных о запасах).
• Немного сложно встать и работать с ним, и это дорого, а лицензия и цена затрудняют использование размещенного экземпляра с ним: вам нужно иметь дело с sysadminning этим самим, вместо того, чтобы использовать что-то вроде Postgres on Heroku или Mongo at MongoHQ

Я уверен, что мне не хватает некоторых с каждой стороны, и хотя у меня есть 3 перечисленные в недостатках, я думаю, что преимущества перевешивают их в большем количестве случаев, когда недостатки не исключают его использования. Цена, вероятно, та, которая предотвратит ее использование в большинстве небольших проектов (что вы ожидаете преодолеть 1 год бесплатной пробной версии).

Cf. это короткое сообщение описывающее Datomic просто для получения дополнительной информации.

Выразительность (c.f. Datalog) и неизменяемость являются удивительными. Это так весело работать с Dataomic в этом отношении, и вы можете сказать, что это мощный, просто используя его немного.

Ответ 2

Одна важная вещь, если учесть, что Datomic подходит для вашего приложения, - это думать о форме данных, которые вы собираетесь хранить и запрашивать, - поскольку данные Datomic на самом деле очень похожи на тройки RDF (понятие понятия первого класса) он очень хорошо подходит для моделирования сложных отношений (связанных данных графа) - то, что часто громоздко с традиционными базами данных SQL. Я нашел этот аспект одним из самых привлекательных и важных для меня, он работал очень хорошо, даже если это, конечно же, не что-то исключительное для Datomic, так как есть много других высококачественных предложений для графических баз данных, нужно упомянуть Neo4J когда мы говорим о решениях на базе JVM.
Что касается Datomic схемы, я думаю, что это правильный баланс между гибкостью и стабильностью.

Ответ 3

Чтобы завершить приведенные выше ответы, я хотел бы подчеркнуть, что неизменность и способность запоминать прошлое - это не "волшебные черты", подходящие для нескольких особых случаев, таких как аудит. Это подход, который имеет несколько глубоких преимуществ по сравнению с базами данных с изменяемыми ячейками (которые составляют 99% баз данных сегодня). Стюарт Хэллоуэй демонстрирует это в этом видео: Сопротивление импеданса - наша ошибка.

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

Вот некоторые особенности Datomic, которые я считаю ценными, большинство из которых включено в неизменность:

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

Относительно того, когда не использовать Datomic, вот текущие ограничения и ограничения, которые я вижу:

• вы должны быть на JVM (существует также REST API, но вы теряете большую часть преимуществ IMO)
• не подходит для масштабов записи, а также для огромных объемов данных
• не будет особенно интегрирован в рамки, например, вы не найдете в настоящее время библиотеку, которая генерирует конечные точки CRUD REST из схемы Datomic
• это коммерческая база данных
• Так как чтение происходит в процессе приложения ( "Peer" ), вы должны убедиться, что у Peer достаточно памяти для хранения всех данных, необходимых для прохождения в запросе.

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

В качестве аналогии вы можете задать себе тот же вопрос для Git по сравнению с другими системами управления версиями, которые не основаны на неизменности.

Ответ 4

Просто чтобы предварительно добавить другие ответы:

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

Я говорю только частично масштабируемое, потому что запросы должны вписываться в одноранговую RAM или терпеть неудачу. И не исключительно впечатляющие, поскольку первоклассные SQL-двигатели могут оптимизировать запросы, чтобы вписаться в память с помощью сложных планов выполнения, что я еще не видел в качестве функции в datomic; Datomic развязка транзакций и запросов может в общем смещении этой функции.

В отличие от многих движков NoSQL, транзакции являются первоклассными гражданами, что ставит его на равных с системами РСУБД в этом ключевом отношении.

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