• Ленивый event sourcing или как жить сегодняшним днем
    0
    relgames есть примеры сложных запросов? какие инструменты использовались и где были максимальные проблемы с производительностью?

    Спасибо!
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    пока что в проекте нет eventual consistency, поведение ближе к стандартном поведению многих баз данных. Есть предложения на тему как лучше всего «заложить» это в проект заранее? Я пока себе это представляю как набор требований выставляемых «поставщиком» конкретной команды — насколько ему важно гарантия проиндексированных данных, или хватит гарантии журналирования, чтобы перейти к следующим шагам быстрее.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    логично, черт побери — мы плаваем между двумя трейд-оффами тут. либо быстро но eventually consistent, либо медленно. есть другие предложения?
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    да, пока нет конфигурации на тему когда индексирование должно происходить, индексы будут просаживать производительность записи приблизительно также как и в традиционных реляционных бд
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    Да, вы правы, это можно и так рассматривать! :)

    С моей личной практической точки зрения, это тот «низкий» порог «угадывания» который меня устроил. Мне не нужно угадывать какие будут структуры моделей, как нужно со временем менять модели и мигрировать данные, мне нужно только время от времени добавлять индексы к полям, причем совсем необязательно перед тем как события записаны — индексы можно добавить в любой момент.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    Да, это «вывернутая наизнанку» доменная модель, однако в этой модели мне не надо угадывать что будет в будущем, просто честно собирать данные и «разворачивать» доменную модель так как мне нужно.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    1. Явно выраженных гарантий по поводу индексов еще нет (но скорее всего будут), пока это факт реализации и некоторых тестов — индексы появляются по факту коммита транзакции (scope транзакций — команда), перед тем как контроль «вернется» к отправителю команды, то есть по сути идут вместе с транзакцией.
    2. Только в некотором смысле — в том плане что я сохраняю данные в событиях в таком виде в котором использование индексов для того чтобы найти эти события было настолько тривиальным насколько это возможно. Случаи, когда таки приходится делать агрегацию событий для оптимизации конечно происходят, но я стараюсь это свести к минимуму.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    Конечно, на поверхности! Ничего сверх-нового. Мои усилия на тему чтения истории агрегата сейчас таковы: 1) оптимизация поиска (индексы используют CQengine, память/диск) 2) организация события в таком виде при котором легко запрашивать без over-fetching.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    Спасибо за комментарий!

    Я не писал, что нужна обязательно реляционная база данных, выше в комментариях я написал «часто это реляционная база данных». Доменную модель и правда можно хранить где угодно. Если доменная модель в памяти, это не значит что read side нету, просто она в памяти.

    Можно прекрасно делать то что вы описываете («кешировать в памяти доменную модель из которой и брать нужные вещи, In-memory cache можно восстанавливать по событиям при старте приложения») однако это не решает ту задачу которая была передо мной — избежать планирования доменной модели («предугадывание будущего»), и дорогостоящих «переигрываний» событий.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    масштабируется — да. но это не решает проблему (которая для кого-то проблема, а для кого-то — нет) с нежеланием предугадывать будущее (соотв., строить read side модели). у меня это было задачей :)
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    пока что ничего сильно сложного (но проект еще очень молодой). сейчас writedb (журнал) реализуется через MVStore (движок от H2), так как в моей текущей модели я разрабатываю приложения со «встроенным» хранилищем (через интерфейс можно, конечно, добавить любые другие реализации. например, более раннии инкарнации этого проекта использовали postgresql по умолчанию).

    если разбивать файлы в которых лежат необходимые ключи (например, consistent hashing или на исторические «отрезки») и хранить на независимых устройствах (в терминах дисков ли, или сетевых устройств) то можно обеспечить сценарий в котором чтение из writedb практически независимо от записи. пока что этого ф-ционала нет, но это интересная тема!
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    отличный анализ!

    по итогам:
    1. более актуальная информация чем в традиционном варианте — уже лучше.
    2. как я упоминал в статье, конечно есть случаи когда массовые выборки будут медленными, и так или иначе агрегировать и/или кешировать данные надо. идеального мира нет :)
    3. не обязательно, это зависит от того как она устроена. append only дает определенные преимущества.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    по сути, да. индексы содержат все проиндексированные данные и соотв. ссылки по которым быстро достаются любые события и откуда можно узнать все данные которые были записаны в событии.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    Идея в том что не строится state db согласной некой модели данных, а только записываются события и они же индексируются (простые индексы по полям, или более сложные композитные индексы). вместо того чтобы записывать изменения в таблицу Users (например), и искать пользователя там, мы просто ищем события которые дают нам минимально необходимое понимание о том что произошло (в случае примера в статье, UserCreated(id) и последний EmailChanged(user: id). Ищем их не перебором, а по индексам (индексы могут быть определены как заранее, так и после записи событий).

    При этой модели, state db в классическом понимании нет, как нету и «единой» модели данных.

    Так понятней, или все еще плохо объяснил?
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    мне кажется, важно вот какое замечание сделать: разделение на write side и read side было и остается, но read side представляет собой не около-конечную модель данных а «сырые индексы» и сборка моделей происходит (в большинстве случаев) в рантайме. Соответственно, нет необходимости «предугадывать» будущее.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    В существующей реализации, event store на самом деле (внутри) — две базы, одна — журнал, другая — индекс. Можно рассматривать их совокупность как одну event store, либо как event store + state db, где стейт — это просто индексы событий.
  • Ленивый event sourcing или как жить сегодняшним днем
    0
    AigizK, запрос на чтение в «традиционной» модели отправляется в state db (часто это реляционная база даннных); в ленивой модели запрос уходит в event store (который не только журналирует события, но и индексирует их). так понятней?
  • Email потерял дефис
    0
    там все проще — это необходимые телодвижения которые они вынуждены делать чтобы не потерять права на свою торговую марку
  • Elixir
    0
    /me умывает руки.
  • Elixir
    –1
    да ну, а в языке Си и не знали что нельзя делать сепаратор ";"
  • Elixir
    0
    А племя мумба-юмба обходится даже без алфавита ;)
  • Elixir
    0
    case Frame#video_frame.codec of
    h264 -> handle_h264(Frame)
    ; aac -> handle_aac(Frame)
    ; pcma -> handle_pcma(Frame)
    end
  • Elixir
  • Elixir
    0
    А что если это была ошибка?

    handle_frame(..) ->
    ...;
    handke_frame(..) ->
    ...


    В данный момент об ошибке сразу станет известно на этапе компиляции. В случае «умного парсера» — в лучшем случае на этапе тестов. В худшем — в продакшне когда function_clause вывалится в лог.
  • Elixir
    0
    предложения как решить это на уровне парсера?
  • Elixir
    0
    а человечнее имхо было бы сделать

    handle_frame(Frame),
    ..
    handle_frame(#video_frame{ codec = h264 } = Frame) ->
    ...
    ну и так далее по тексту

  • Elixir
    0
    по сути ответа на пример с if'ом не было ;)
  • Elixir
    0
    С другой стороны, позитивный момент в том что все больше интереса к erlang vm и его принципам. Да, эти все языки-надстройки скорее лишний барьер на пути к ерлангу, но про позитивные индикаторы не стоит забывать.
  • Elixir
    0
    мне кажется вообще, что эта проблема совсем не уникальная для erlang. switch/case statement не утомляет в C? или в сложных or/and конструкциях в условиях в любом языке нас же не удивляет что последний or или and оператор надо тоже удалить?

    По поводу последнего, представим такой код:

    if ( (flag & TCP_NOKIDDING) ||
    zlag < Z_LAG_THR ) {
    ...
    }


    предположим, последнее условее более не надо

    if (flag & TCP_NOKIDDING) {
    ..
    }


    сколько строчек поменяется в гите? правильно, тоже две.
  • Elixir
    0
    Меня лично это момент ничуть не утомляет. Однако можно попробовать нестандартное форматирование?

    case Frame#video_frame.codec of
    h264 -> handle_h264(Frame)
    ; aac -> handle_aac(Frame)
    ; pcma -> handle_pcma(Frame)
    end
  • Elixir
    0
    Но ведь это не про «почему-то», это же вполне ожидаемое поведение.
  • Elixir
    0
    Примеры «иногда»?
  • Elixir
    0
    Мне вот все еще интересно, откуда выплывает утомление от знаков препинания?
  • Elixir
    +2
    1. records? (они, конечно, не идеал, но задачу именованных полей решают весьма сносно).
    2. И как следствие, я нахожу pattern matching по records весьма удобным. Можно примеры кода который напрягает?
    3. Вас напрягает зависимость от знаков препинания в натуральном языке? В erlang, как по мне, весьма логичная схема. Если думать о ф-циях как о предложениях, все становится на свои места. Мы же не ставим точку посреди предложения? Коньюктивы отображаем как запятые? Ну а точка с запятой — это «или» — что то вроде «Мы можем поступить так; или можно пойти другим путем». С этой аналогией мне в свое время стало легко вкуриться в синтаксис.

    learnyousomeerlang.com видели?
  • Elixir
    0
    Это все понятно, но вопрос вот в чем: где начинается затык у Васи из Челябинска?
  • Elixir
    +3
    Вот я до сих пор пытаюсь понять, в чем страшность Erlang? Где именно начинается непонимание?
  • Elixir
    0
    «Elixir способен просматривать и модифицировать структуру объекта во времени исполнения.»

    seriously?
  • Покупали номер без оформления? И зря!
    0
    по крайней мере в штатах не надо — для чистых препейдовых аккаунтов, сам брал такие телефоны… в Канаде какие-то аналогичные продукты вроде тоже есть (solo mobile?), но я не знаю точно, сижу на контрактах…
  • Кто такой moneymaker
    0
    заглавные буквы скорее калька с английских правил (Titles Capitalization)
  • континуации и stateful веб-программирование (Updated!)
    +2
    RESTfull => RESTful
    statefull => stateful