Я посмотрю. Но трудно представить, чтобы базу в десятки гигов заменить загрузкой в память чего-бы-то-ни-было...

Трудно, но в банковских энтерпрайзах часто используется этот паттерн. Он даёт возможность отслеживать стейт сущности в любой промежуток времени. Такая вот себе машина времени🙂

Это наверно требует немалых ресурсов...

Ну из того что я сталкивался, там была не вся база в мемори, а только транзакции и документы. Нынешнее состояние дублировалось в редис кластер для нескольких нод на чтение. Всё остальное было в оракле. Ну в общем немного гибридная архитектура🙂 на холодный запуск требовалось около пары часов. Но такого по идее вообще не должно быть.
Там есть ещё понятие как снапшоты. Те для быстрого запуска можно сохранять конечное состояние сущности по времени. А вот если нужно историю посмотреть, то тогда уже процесяться все операции с самого начала.
Я где то слышал что и приват наш юзает такую архитектуру.  Но не уверен😀

Без реляционной "хард" базы не обошлось. Думаю без нее - в принципе нереально - где-то же надо хранить данные.

Я думаю она там просто по наследству перешла🙂 просто всегда нужно понимать где нужно применять этот паттерн, а где нет🙂

данные хранятся в аппенд-логе, то есть записываются в файл, но в отличие от sql баз в файл записываются изменения и при этом в конец файла что очень быстро (200мб/секунду на обычных не ссд дисках), благодаря этому обработка транзакций позволяет достичь нескольких сот тысяч в секунду. В общем советую посмотреть этот доклад чтобы понять что такой подход является одним из самых передовых и явно лучше чем sql-базы - https://www.youtube.com/watch?v=yrTF3qH8ey8

применять стоит везде за исключением случаев когда данные не влезают в оперативку. Но сейчас уже можно арендовать сервера объемом до 4-х терабайт оперативки (на том же амазоне) поэтому для 99% стартапов этого будет достаточно

я согласен, что быстрее при одной записи в конец файла, чтение с конца - тоже супер,
но как получить разные выборки для отчетов например? По отдельному юзеру, по дате и т.п.
Не отвечай...
Доклад конечно посмотрю.

"объемом до 4-х терабайт оперативки"
"для 99% стартапов этого будет достаточно"
наверно дорого...

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

круто! надо попробовать :)

подход бд в оперативке в банковских энтерпрайзах используют потому что сайчас это самый эффективный и дешевый способ получить serializable-транзакции, вот доклад на эту тему https://www.youtube.com/watch?v=5ZjhNTM8XU8

Интересный доклад от разработчика тарантула, но он правда из 2015. И уже тогда докладчик говорил, что быстрые SSD изменят баланс с базой в памяти и на диске.

Я уже использую такой подход =). Более того c таким подходом такие технологии как rest и graphql становятся не нужны потому что я могу просто описать любой запрос к бд на клиенте а специальный плагин к babel на этапе сборки просто соберет эти запросы и загрузит их в базу данных.
Вот пример (на реакте) - в onClick кнопки пишем отправку запроса на сервер вызывая функцию REQUEST и тут же передаем помимо аргументов запроса и сам запрос - то есть пишем на клиенте сразу и логику обработки этого запроса в базе данных.

<button onClick={()=>{
 const { todoId } = this.props;
 const todo = await REQUEST(todoId, this.state.newSubTodoText, (db, session, todoId, text) => {
  const todo = db.tables.todos.find(todoId);
  db.tables.subtodos.create().update({todo, text});
  return {
    id: todo.id,
    text: todo.text,
    completed: todo.completed
    subtodos: todo.subtodos.map(subtodo=>({
      id: subtodo.id,
      text: todo.text,
      completed: subtodo.completed
    }))
  }
 });
 this.setState({todo});
}}>...</button>

А функция REQUEST является на самом деле макросом - на этапе сборки запрос внутри заменится айдишником и загрузится в базу а на клиенте будет происходить просто передача айдишника запроса вместе с аргументами

const todo = await REQUEST(todoId, "ID_2323223");

В итоге я могу аналогично grapqhl на клиенте вытащить необходимые данные просто возвращая объект и вложенные массивы с объектами через .map()
A поскольку база данных  находится в оперативке и данные в ней храняться как обычные js-объекты которые связанны ссылками то такая бд предоставляет удобный интерфейс для обращения к связанным сущностям - я могу в цикле обратиться к глубоким сущностям

const allSubtaskPrice = await REQUEST(projectId, (db, session, projectId)=>{
 let subtasksPrice = 0;
 const folder = db.tables.projects.find(projectId);
 folder.projects.forEach(project => {
  project.tasks.forEach(task => {
    task.subtasks.forEach(subtask => {
       subtasksPrice += subtask.price;
    })
  })
 }
 return subtasksPrice;
}

или наоборот могу из глубокой сущности через точку обратиться к родительской сущности

const folderPriority = await REQUEST(subtaskId, (db, session, subtaskId) => {
 const subtasks = db.tables.subtasks.find(subtaskId);
 return subtask.task.project.folder.priority;
})

И в отличие от graphql мы имеем возможнось описать на клиенте не только какие вложенные сущности нужны а и гибко их обрабатывать, фильтровать а также проверять права доступа или сокрытие важных полей и т.д
Ну и также в отличие от graphql на клиенте можно заодно и описать логику изменения данных.
И главное - описывая таким образом модификацию данных то к какому количеству данных мы бы не обращались и как бы мы данные не меняли - в базу данных будет отправлен один единственных запрос он будет обработан как одна атомарная транзакция (без всяких race-conditions) - то есть имеем честные serializable транзакции на скорости до  200к запросов в секунду

Кто пользовался библиотекой pg; для чего в Pool есть метод connect(), возвращающий одно соединение? Ведь пул спроектирован для нескольких конкурентных конекшенов by design. Есть какое то практическое применение в использовании pool.connect() вместо просто new Client(...)?

Доброе утро, подскажите, есть ли похожие «чат-комьюнити» с он/оффлайн митапами, только по Python с фокусом на nlp?

На dou было что то

Ссылку/Поисковые ключи помните?