Fork me on GitHub
#clojure-russia
<
2015-07-04
>
niquola06:07:23

simple_smile а дальше? Мы, в основном, honeysql используем

linuccio06:07:11

Тоже этот вопрос интересует

linuccio06:07:38

И ещё, что в функциональном программировании и Clojure вместо моделей данных как в ООП ORM`ы

linuccio06:07:09

Имею в виду, что если нет необходимости в ORM, то в какую сторону мне мышление сломать simple_smile

delaguardo06:07:43

как раз когда не нужно ORM

delaguardo06:07:32

использовал его как раз с постгрёй

dmitrygusev07:07:06

для динамических запросов не подойдет он

dmitrygusev07:07:16

когда нужно менять чуть-чуть структуру запроса

dmitrygusev07:07:48

а часто нужно так делать — строить запрос налету

dmitrygusev07:07:49

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

dmitrygusev07:07:43

в java это все хорошо делают jOOQ и QueryDSL, например

dmitrygusev07:07:16

в Clojure в этом плане https://github.com/korma/Korma похожа

dmitrygusev07:07:54

генератора только нет в ней, чтобы по схеме базы наделать defentity, удобно было бы

dima07:07:14

postgresql -> raw sql -> clojure maps (no ORM)

delaguardo07:07:35

Почему повторно не получится? Все запросы можно определять в одном файле как именованные функции

delaguardo07:07:43

Да, в этом файле будет много дублирования, но в SQL это и не проблема, имхо

delaguardo07:07:48

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

dmitrygusev07:07:14

>>>The problem with SQL is that it's a custom language. Using SQL from other languages causes a host of other problems - problems that are orthogonal to querying a database. These problems are examples of accidental complexity, complexity in an application caused by the tool used to solve a problem rather than the problem itself.

dmitrygusev07:07:37

Там есть ссылка на разговор Рича. Я не скажу точно тот этот доклад или нет, но он как-то говорил про проблемы SQL. В том числе, что для SQL нет API Копировать-вставлять SQL наверное можно, но писать этот SQL руками для сложных выборок не очень удобно

dmitrygusev07:07:36

в текущем проекте у нас есть запрос примерно в 1000 строчек, у которого есть пару десятков вариаций, когда меняется предикат немного

dmitrygusev07:07:53

не могу представить как это сделать статическими запросами

dmitrygusev07:07:04

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

linuccio07:07:17

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

linuccio07:07:50

Фильтры товаров, или статистики

dmitrygusev07:07:39

для некоторых фильтров еще могут понадобиться дополнительные join'ы

dmitrygusev07:07:04

и еще если это дело сортировать, то может понадобиться в проекцию добавлять дополнительные поля

dmitrygusev07:07:10

там много нюансов

linuccio10:07:04

А миграции бд кто как делает?

linuccio10:07:16

есть вроде активный ragtime

linuccio10:07:22

но там sql

linuccio10:07:54

нет ли живого dsl для редактирования схем/миграций?

niquola10:07:12

Мы активно используем honeysql и небольшую собственную обертку над ней. Это дата дсл. Так же в одном проекте хорошо легла prizmatic schema для коэрсинга и валидации.

niquola10:07:53

В clojure.jdbs встроен простенький dsl для миграций.

niquola10:07:32

Мы пользуемся в основном самописной, но есть ещё https://github.com/ckuttruff/clj-sql-up и https://github.com/weavejester/ragtime

linuccio10:07:07

Прекольно simple_smile

niquola10:07:26

Для поддержки jsonb и массивов в postgresql - https://gist.github.com/niquola/91d94e1a51291e7db001

niquola10:07:26

Для поддержки jsonb и массивов в postgresql - https://gist.github.com/niquola/91d94e1a51291e7db001

niquola10:07:08

Там в gist и реализация миграций заодно

linuccio10:07:33

а какая разница между korma и honeysql?

linuccio10:07:47

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

linuccio10:07:53

семантически более далёкой от sql

niquola10:07:37

honey очень маленький data dsl для написания sql в духе hiccup

niquola10:07:12

В этом и прелесть - остальное сам ;)

niquola10:07:34

Вобщем honey библиотека, а korma фреймворк. Мы дописали например eager-loading для honey на 50 строчек - если интересно могу выковырять

linuccio10:07:47

Если не сложно simple_smile Просто сейчас стоит вопрос о выборе

linuccio10:07:02

Минимализм прельщает конечно

linuccio10:07:15

Давно уже смотрю разных БД развелось, но кроме SQL ничего не пробовал

linuccio10:07:26

В то же время MongoDB удивляет скоростью

linuccio10:07:54

В мире Clojure есть что-то более предпочтительное в этом плане?

linuccio10:07:08

Или MongoDB фаворит?

niquola10:07:06

Datomic ;) true clojure db

niquola10:07:26

Монго объект насмешек

linuccio10:07:47

Ага, но я правильно понимаю, что для серьёзных занятий Datomic нужно покупать?

linuccio10:07:05

Просто у меня клиенты пока не такие богатые)

niquola10:07:49

В принципе, postgresql с jsonb закрывает значительную часть возможностей mongo

niquola10:07:24

И даёт acid & sql в дополнение

delaguardo10:07:31

для сильных духом есть Cassandra, как замена Mongo

niquola10:07:15

@delaguardo а вы касандрой пользовались?

niquola10:07:41

Если объёмы до террабайта я бы выбирал postgresql

delaguardo10:07:54

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

delaguardo10:07:15

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

delaguardo10:07:06

в итоге перехали на influx, хапнули с ним тонны фэйлов и сейчас разворачиваем кластер из PostgresXL

ilshad11:07:52

@linuccio в принципе там разумная ценовая политика. Pro бесплатен для 2 пиров и одного транзактора, других ограничений нет. По сути это означает, что - для одного пира, т.к. второй лучше оставить свободным для Datomic Console. Весь jvm-процесс - это один peer, поэтому можно цеплять много сервисов, если разворачивать их в одном из джавовских аппликейшн контейнеров. Мы так и делаем, чтобы архитектура не зависела от прайса. Апгрейд на большее количество пиров подразумевает больше нагрузок, и на серверы без всякого дейтомика денег уйдет еще больше чем на его лицензию.

ilshad11:07:49

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

ilshad11:07:24

Поэтому на амазоне сейчас будет, в минимальной (но production) конфигурации, прядка 40 долларов: 20 за t2.small для транзактора и 20 за DynamoDB.

ilshad11:07:31

(в месяц)

ilshad11:07:08

на зато никакой возни с БД, а возможностей куча

linuccio11:07:05

Пробовать в любом случае буду, но проприетарность настораживает всё равно

ilshad11:07:18

угу, согласен

linuccio11:07:01

Посмотрел на Postgres (давно не смотрел, в основном MySQL использовал) - производительность впечатляет

linuccio11:07:25

Так что действительно в MongoDB смысла не много с этой точки зрения

delaguardo11:07:29

@ilshad: я так понимаю вы его в продакшене крутите? можете поделиться цифрами как оно себя под нагрузкой ведет?

ilshad11:07:47

да, в продакшн

ilshad11:07:28

но отчет в цифрах делать не готов прямо сейчас simple_smile

delaguardo11:07:21

жаль, хотелось бы узнать насколько сейчас Datomic готов для высоких нагрузок

ilshad11:07:57

@delaguardo: пробегись по гугл-группе дайтомика

ilshad11:07:21

там обсуждают

delaguardo11:07:45

@ilshad: не заглядывал туда, спасибо