@bernik вроде тока датомик, есть еще mentat от мозилы сделаные по образу датомика+датаскрипта (https://github.com/mozilla/mentat) но вроде immutability там нету, хотя я не уверен. Если других вариантов нет, а датомик не канает в силу каких то причин то можно сделать самому (ну не весь датомик конечно ), либо руками везде пихать триггеры на все таблицы, либо старый (анти)паттерн EAV модель, как например вот тут http://weblogs.sqlteam.com/davidm/articles/12117.aspx

Еще интересный вариант взять какую-нить queue систему (Apache Samza) посередина и пушить все изменения/создания туда как например в этой статье http://dchambers.github.io/articles/databases-are-dead/

Ну и еще отсюда https://news.ycombinator.com/item?id=11689674

I believe you're describing what is typically referred to as an "append only" datastore.
The biggest-name in the game is Google BigQuery

во нашел https://github.com/mirage/irmin, на окамле аж, годно

интересно что почти все статьи про immutable databases написаны авторами которые знают и юзают Clojure. Т.е. с одной стороны датомик да, с другой стороны immutable data structures есть много в каких языках, а такое ощущение что тока кложуристы подсаживаются на это с полной силой 🙂

в каком-то смысле rethinkdb это поддерживает https://www.rethinkdb.com/docs/changefeeds/ruby/

там компания вроде как загнулась, но лут с трупа собрали и теперь она доступна в опенсурсе https://www.theregister.co.uk/2017/02/07/rethinkdb_lands_license_to_live/

ну вот как-то так и получается, что все городят какие-то кастыли(триггеры, отдельные таблички versions/history), а искоробочного варианта нет. с другой стороны, в датомике эта hisory-db никак не настраивается, насколько я понимаю. нельзя настроить время жизни этого лога(потому что удалять нельзя) или, хотя бы, какой-то механизм типа git rebase, который бы в общем случае выглядел бы как reduce по истории

Мы в postgresql только вставляем - по две таблички всех сущностей делаем

Как раз полный контроль над историей получается, но не из коробки.

Интересно что в статье по дизайну постгреса от 80 года был пункт про сохранение историчных данных и запросы над ними - из этого остался только mvcc

https://www.google.ru/url?sa=t&source=web&rct=j&url=http://db.cs.berkeley.edu/papers/ERL-M85-95.pdf&ved=0ahUKEwjOwMj6npTSAhUGVywKHRcDAPcQFggiMAM&usg=AFQjCNHU3kdy-34H89NgLkjxNVbtOUk99w&sig2=-M6EFe4zbT_YukEWW5YrQg

Те если в PG выключить вакуум - оно и получится ;)

Можно наверно упороться и пропатчить PG для этого

https://m.habrahabr.ru/post/208400/

У нас что-то типа такого - http://clarkdave.net/2015/02/historical-records-with-postgresql-and-temporal-tables-and-sql-2011/, но без тригеров

@bernik Вот удаление старых данных: http://docs.datomic.com/excision.html

rebase не нужен. точнее, rebase вреден. зачем портить историю?

вместо эксижена рекомендовали менять базу, как rolling log file appender. что бы окно хистори было сколько-то месяцев/лет крайних

типа эксижн - на случай судовых требований и тд. и он не удаляет-удаляет, а что-то за собой оставляет, tombstone какой-то

с учетом этого всего и лимита датомов, есть смысл данные делить на несколько баз сразу, чтобы "индивидуально" принимать решения и иметь дело с ростом хистори

типа юзеров - в одну, заказы - в другую, аналитику пользования приложухой - в третью.

@dottedmag такой rebase скорей для оптимизаций вида истории. например сделать squash мелких изменений в одно большое, чтобы не делать тоже самое каждый раз когда захочется посмотреть историю изменения документа

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

скажем, я пишу сервис отслуживающий фоловеров. т.е. нужна история изменений сета с айдишниками. Что бы я сделал в SQL: таблица 1: колонки user_id, timestamp, follower_id (+ фоловер подписался, - отписался) таблица 2: хранит последнее известное состояние (список id фоловеров). чтобы показать историю, беру текущий стейт из второй таблицы и отматываю до нужного таймстампа по первой. итого два селекта

это об этом?

@andmed тебе презентации Хикки про бд смотреть надо - там убедительно

харизма у него есть, согласен

не в харизме дело

в джаве ты тоже можешь руками "атомы" менеджить между тредами без канкаренси проблем, только за###шься

т.е. пойнт в изоляции, не в хранении бэклога?

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

потому посмотри презентации - там комплексно описано, чем датомик четкий: запросы на клиенте, кеш на клиенте, бесплатный скейлинг на чтение, запросы по истории, любой сторадж и тд

но персистентные бд вроде решают задачу хранения истории, да

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

можно мой случай изменить так, чтобы был смысл смотреть на датомик?

ну и канкаренси решают. типа консистентный результат запроса по бд на момент времени t

датомик имеет смыл смотреть для общего развития расширения сознания как минимум

@misha а ты его юзаешь в итоге где?

ну кроме как поиграться и забыть я имею ввиду

не вот мне правда интересно понять смысл, юзкейс так сказать

там же где и реакт нейтив, но последние полгода+ я в мобилочке колупаюсь, бекенд не трогал совсем, но синк датаскрипта с датомиком у меня черновой нахачен уже

@andmed какой юзкейс у кложи?

речь о персистентой бд, это более экзотичная вещь чем кложа. не?

у меня юзкейс: на мобиле датаскрипт, на сервере датомик, синхронизация - 2 страницы кода. сохранение кложа-типов при записи/чтении, запросы по истории, даталог и пулл-паттерны динамически можно собирать (а не бл##ские sql строки плюсовать)

я спросил, чтобы показать, что любой однофразовый ответ - неплоный

ну ты уводишь на sql я просто показал как я бы решал задачу бэклога если я правильно понимаю смысл персистентной базы. насчет sql btw google с тобой не согласен http://datascienceassn.org/sites/default/files/F1%20A%20Distributed%20SQL%20Database%20That%20Scales.pdf

но речь о персистентной базе

datomic по моему - это гибрид orm и базы данных. Как раз персистентные аппендонли DB не уникальны - в смысле что mvcc часто используются для изоляции транзакций, и там оперируют снэншотом базы данных

ну да. бд собаку съели на изоляции

потому и спросил

datomic интересная композиция - append only, search and indexes on pear , triple store ;)

хмммм... tripple store

@andmed уже бы посмотрел половину презентации, пока тут наводящие вопросы задаешь

почему наводящие? я же не утверждаю что персистентные бд не нужны

Я говорил с чувакам из postgrepro - они скептичны насчет эффективного триплстора

Меня расстроило понятие - most selective clause

Это значит, что планировщика и статистики нет в datomic

Или есть?

Те нифига оно не декларативное, раз от порядка зависит

(единственный упрек sql из сообщений выше - конкатенация строк для динамического построения запросов)

@nicola скорость выполнения не декларативная

Ну она достаточно важна, иначе это игрушка, которая начнёт тупить на миллионах записей

На на порядки может быть разница

При этом трипл обрекает на большое количество join и на более менее сложных запросах хьюманбрэйн уже не справится

- комбинаторный взрыв планов выполнения

кажется мне, что ты рассматриваешь характеристику "трипл стор" вне контекста конкретно датомика

А в чем разница?

но фактов у меня никаких нет )

ну там же куча слоёв кеша у них и тд, те же персистентные данные, которые может там чота ускоряют, и тд

вообще, есть же музик дб демочковая - там можно потестить что как быстро работает

Попробуй сделать 10 join 1M записей пусть и в памяти, пусть и по индексам

+ запросы же на клиенте - берешь бокс потолще и задаёшь такие вопросы там

персистентные данные, которые может там чота ускоряют правда?

у меня ни живого апликейшена нет, ни такого объема данных, ни сорцов датомика, так что хз

@andmed что именно правда?)

Тут вопрос откуда исполнение начинать - и планировщик может найти на порядки более эффективный путь

С использованием статистики

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

В общем чтоб считаться полноценной дб у датомик кое чего не хватает

бд?

@andmed ты-то думаешь, что пошутил

да нет, я знаю что датомик "паразитирует" на хранилище))

https://groups.google.com/forum/m/#!topic/datomic/6VkADvLx-QU

@andmed https://youtu.be/Cym4TZwTCNU?t=3561

как раз про время отрывок

@nicola слушай, а ведь можно считать сколько в базе записей конкретного атрибута, и в зависимости от этого менять местами стейтменты в запросе

это и есть первые шаги планировщика

еще нужно заводить статистику на значения

можно нахачить )

и тд

оценивать селективность условия 🙂

So that is what we've decided to do (as of 0.8.3372). Now, in the case of the second query, we will run it in the order you specified and this will run as fast as the first query. If you manually write it in the second order, it will run slowly. But, rather than wondering what is happening in a black box and trying black art things like the [(= ?n 4)] clause, you can simply try another order. 

сейчас девелопер - планировщик

Ага

я может сопляк еще, но мне кажется, что это мелочи всё (руками скорость квери проверять) в сравнении с полезняком датомика

Пока все уместиться в памяти и выборки будут селективными - он будет работать

чем это отличается от невлезшего в память sql запроса (который с планировшиком)?

тем, что тут лёг 1 пир, а там - вся бд

Тем что PG за секунды лопатит запросы с миллионами строчек и без индексов

Вобщем надо побенчмакркать

т.е. утверждаешь, что у PG всегда "влезет"?

он mmap делает - не обязательно в память влезать

а сколько в вашем (мед?) продукте разных запросов? и сколько из них таких тяжелых

ну просядешь на порядок

а в датомике на несколько

если про ehr - сотни

несколько десятков - тяжелые

но я боюсь что в датомике они бы на пол дня зависли

нужно проверять

отдебаженые? в смысле "с хорошей перестановкой уже"

ты имеешь ввиду оптимизированные

?

that's the word

проблема в том, что оптимизация может от данных зависеть

у одного пациента 10 лаб резалтов, у другого 1000

у некоторых 10К

и у тебя нету one fit all запроса

а разве так часто бывает, что сегодня abc запрос в 10 раз медленнее, чем acb, а завтра наоборот, а послезавтра снова?

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

представь тебе нужно сджойнить три таблицы

на каждую из них наложены условия

например для одного пациента оценка выдаст t1 - 100 rows, t2 - 100000 rows, t3 - 500rows

и ты начнешь с t1

а у другого наоборот t1 - 100000, t2 - 1, t3 - 2

и тут бы хотелось с t2 начать

и приехали - на первом все летает, на втором висит

ну вот я перебираю пару доменов, пытаясь найти "такие 3 таблицы"

ну если у тебя в основном крудик и выборки на одной таблице - то все ок

в бд метаданных для кино в сони такого нет, даже с учетом того, что там пере-импортировались данные для фильма сотни раз не перетирая, а аппенд онли

т.е. если там вспухает таблица какая-то - она скорее t3 всегда, а чтоб вспухла t1 - таких бизнес запросов нет просто

даже типа "все метаданные (t3-tn) для всех видео (t2) парамаунта (t1)"

в канале datomic вроде начали отвечать

stuartsierra [3:41 PM] 
<@U0514TE0F> It means that you are responsible for monitoring and optimizing the performance of your queries based on your data. Future releases of Datomic may be bundled with tools to assist in this analysis, but they are not part of the current release.

🙂

мне всё еще кажется, что твой пример надуманный можно acceptably заоптимизировать раз, и через пол года перепроверить актуальна ли оптимизация (помножить на пару десятков тяжелых кверей в твоём проекте)

у тебя запрос зависит от параметров - так?

в зависимости от параметров - вернутся разные данные

ну я понимаю о чем ты. всегда же можно оценить самый неудачный случай

и тут ситуация что ты не можешь написать один запрос для разных параметров и данных

те тут принципиальная зависимость - эффективности запоса от данных

можешь, просто он будет не максимально медленным и не максимально быстрым

которой нет в datalog

но будет acceptable

и раз в месяц все твои пиры будут виснуть на каком нибудь ворст кейсе

там жеж кеш!

либо ты в коде начнешь изобретать планировщик

кэш не поможет при джойне 10 милионных коллекций

для начала хочу, чтобы у меня появились "все мои пиры" 🙂

10 * 1М nested loop - будет занимать несколько секунд а то и десятков

а что за запрос такой, в котором надо 10м джойнить? надо ж пофильтровать 10м сначала

даже в памяти

в случае с datomic это все может на одной сущности произойти

или пагинацию там, если у тебя слишком больной пациент

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

Ну, да. Workload более-менее известен, а если меняется - всё равно надо заново смотреть, как что происходит.

@misha Даже периодически проверять на надо, а просто впихнуть инструментирование и глядеть, если время запросов начинает вылезать за лимит.

@dottedmag я ~ о том же

может как-то так? приятнее читается

(let [offset (cells-offset coord (-> state :draw :brush))]
  (update state :field (partial merge offset)))

Да. Мне нравится. Спасибо Никак не могу привыкнуть подпихивать let для читабельности

get-in без дефолтного значения лучше заменять на ->? (если ключи это кворды)

не скажу лучше или нет — вкусовщина, но мне больше нравится стрелочка

плюс не надо создавать лишний вектор)

а если еще и шрифты с лигатурами, то стрелочка красивше.

xD

точно!)

А. Так это еще от шрифта зависит. Думал, от темы Всё. Теперь красота

@kgofhedgehogs select-keys + что-то ещё, типа (select-keys s (keep (fn [[k v]] (when v k)) (d :show))) {:framerate 15, :generation 130}

Спасибо

Как лучше? #(update % 0 name) или (fn [[k v]] [(name k) v])

Входит типа MapEntry, где ключ это кворд, а выходит пара ключ значение, где ключ это String

(select-keys s (keys (filter val (d :show))))

@kgofhedgehogs Второе понятнее