×

Почему я не использую реляционные СУБД

«Rather than making my app easy to deploy, I’ll just do a bunch of gnarly shit in Docker» Some CEO

Если вы стартап и начинающий бизнес, то одна из первых задач, которая будет стоять перед вами, — выкатить на вчера хоть что-нибудь. Так как ~90% стартапов умирают в первый же год (цифра 90% разная в зависимости от типа исследования и источника), это требование является довольно разумным и очевидным. Нужно как можно быстрее проверить гипотезы, понять, нужен ли ваш продукт хоть кому-нибудь и попытаться подписать первых клиентов уже хотя бы на стадии MVP, в общем — продать хоть что-нибудь. В условиях постоянной спешки и постоянно меняющихся требований нет никакого смысла проектировать крутое и гибкое ядро. Эта инвестиция никогда не окупится, кроме случая, когда это ядро является самим продуктом.

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

В мире стартапов и начинающего бизнеса денег нет. Есть только немного человеческого ресурса. Спека? Пффф... Это непозволительная роскошь. Тестеры? Пфф... Девопсы? Ну вы поняли.

Все приходится делать самому. И базы данных тут сплошная помеха. И сразу по нескольким причинам.

СУБД медленные

Уверен, что каждому опытному разработчику приходилось тюнить какой-нибудь запрос или саму базу. Переключать движки с InnoDB на MyISAM, изменять размер кеша под конкретное железо, смотреть на план выполнения запросов, думать о правильных индексах и искать компромисс между нормализацией, дубликацией данных и скоростью.

Уже давно не секрет: современная СУБД 90% времени тратит на обслуживание своих подсистем — логирование, блокировки, менеджмент памяти, планировщик запросов, парсер, лог транзакций и т.д. И лишь 10% собственно на выполнение нужного клиенту запроса. То есть огромное количество ресурсов тратится впустую. Просто потому, что для большинства приложений из прошлого это было необходимым функционалом.

Каждый раз, когда вы делаете:

userDao.save(user);
//insert into users (id, name) values (?, ?);

Я делаю:

try (BufferedWriter writer = Files.newBufferedWriter(fileTo, UTF_8)) {
  writer.write(user.toJson());
}

Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает.

Запросы — это дорого

Если решить вопрос с медленными СУБД еще возможно переходом на заточенные под конкретную задачу решения, то с выполнением самого запроса уже труднее. Даже если у вас есть пул соединений, и вы не тратите ресурсы на их открытие.

Только представьте себе длину пути всего запроса в типичном java приложении: request → ORM → jdbc driver → network → DB, и в обратную сторону.

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

Каждый раз, когда вы делаете:

user.setName("'Peter'");
userDao.update(user);
//update users set name = 'Peter' where id =  ?;

Я делаю:

user.name = "'Peter'";

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

RAMа так много, что диск нужен лишь меньшинству

Люди инертны, но мир меняется очень быстро. И он уже изменился. Смиритесь с этим. В то время, когда Amazon запускает сервера с 2 ТБ RAM, а средний java сервер — это 32 ГБ RAM, люди добавляют в проекты СУБД просто, чтобы сохранить там 1-2 ГБ данных.

Вы можете хранить все в памяти. Для многих приложений этого будет более чем достаточно. Как минимум, этого будет достаточно для ~90% стартапов, которые умрут, так и не став звездой единорогом. Прикрутить базу вы всегда успеете — когда попадете в те 10%.

Каждый раз когда вы делаете:

User user = userDao.get(name);
//select * from users where name = ?;

Я делаю:

Map<String, User> users …;
User user = users.get(name);

Все пользовательские данные я храню в памяти. Конечно, данных может быть очень много, и все не уместить. Например, в моем случае в памяти хранится все, кроме данных репортинга — так как их действительно много. Их дешевле писать/читать напрямую из диска. 100К активных пользователей — ровно столько я могу обслуживать с 1 ГБ RAM на виртуалке за 10 у.е.

Схемы, схемы, схемы

Чтобы начать работу с СУБД, мне нужна схема. Без схемы я ничего не могу сделать. Я не сажусь писать бизнес-логику — я сажусь и описываю мапинг, зависимость между классами и на основе мапинга генерю схему (ну хоть на этом спасибо ORM). Но бизнес не интересует схема. Ему нужно сделать на вчера. Я мог бы спроектировать крутую нормализованную схему как на рисунке ниже. Но зачем?

Схему нужно постоянно поддерживать. Когда у вас нет продакшена — это легко. Но как только у вас появился первый клиент, вы в тупике. Luiquibase, flyway — классные тулы. Но вы их используете, когда вы уже в тупике. Вы не можете сделать изменение в модели, ничего не поломав. И еще вам нужны роли, пользователи, разграничение прав доступа, разные базы данных. А бизнесу нужно на вчера.

Когда вы пишите:

@Entity
@Table(name = "Users")
public class User {

    private Long id;

   @Id
   @GeneratedValue(generator="increment")
   @GenericGenerator(name="increment", strategy = "increment")
    public Long getId() {
        return id;
    }
}

Я пишу

public class User {
   public long id;
}

Нет БД? Это несерьёзно

«Это несерьёзно» — фраза, которую я постоянно слышу от матерых сениоров. И это забавно, ведь в большинстве случаев сениор даже и близко не подозревает о потребностях бизнеса.

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

Если бизнес спрашивает: «Какую БД вы используете?» — вы общаетесь не с бизнесом. Бизнесу это не интересно. Клиента интересует лишь то, решает ли система его проблему. И если решает, то по какой цене. Остальное никого не интересует. Ни один наш бизнес-клиент не спросил: «Какая у Вас БД?» И это при том, что все наши клиенты — технические компании!

Когда Вы делаете:

create table users;

Я пишу бизнес-логику.

Базы данных нужно поддерживать

В аутсорсе было хорошо. Мой код — моя ответственность. Все что дальше — не мое дело. Мне легко было добавлять postgres, redis и sharding для них. Сегодня, когда я все делаю сам, я понимаю, что у каждого дополнительного модуля системы есть цена деплоя и стоимость поддержки. Я не буду добавлять БД в проект, пока без нее могу решить бизнес-задачу минимальной ценой.

Добавить БД в проект легко. Но потом ее нужно развернуть локально, развернуть в тестовой среде, развернуть на стейджинге, развернуть на продакшене. А это все работа.

БД нужно мониторить. Она может упасть, там может закончиться диск, выполнение запроса может «подвиснуть», процесс может скушать 100% CPU, БД может начать тормозить, delete может не очищать диск и нужно выполнять vacuum, данные могут быть испорчены и т.д.

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

Пока вы делаете:

https://github.com/docker-library/postgres/blob/e4942cb0f79b61024963dc0ac196375b26fa60dd/9.6/Dockerfile

Я делаю:

java -jar server.jar

О проекте. Наш проект Blynk — IoT платформа с мобильными приложениями. 30К MAU. Текущая нагрузка на систему — 4500 рек-сек. Почти 3000 девайсов постоянно в сети. Всего периодически подключается около 10К девайсов. Аптайм 99,99% за полтора года. Вся система обходится в 120$ (50$ из них Geo DNS) в месяц. Запас прочности — 10х на текущем железе; + 10х возможность вертикального роста. Проект опенсорс, глянуть можно тут.

P. S. Я не призываю вас отказываться от БД. Есть класс задач, где без БД никак, и они действительно упрощают жизнь. Но не стоит бездумно лепить БД в проект лишь потому, что вам нужно сохранить данные на диск.

P. P. S. Статья пролежала в черновиках полгода. Сейчас мы уже используем Postgres (как backup систему) и Redis для лоад балансинга (не бизнес-логика). Все это входит в 120$. Тем не менее, система успешно просуществовала без баз данных 2,5 года.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному4
LinkedIn

Схожі статті




Найкращі коментарі пропустити

Умилился. Реляционку хоронят уже несколько десятилетий, придумывают очередные костыли, холиварят, бьют лбы. Потом опять приходят к SQL и диву дивуются, как раньше без него справлялись.
На самом деле автор прав. В чём? Если не нужен ACID (атомарность, консистентность, изоляция и отказоустойчивость транзкций) — то реляционная СУБД не нужна. Будет быстрее и проще.
Но если на проекте (стартап это или не стартап) есть чёткие требования по конкурентной обработке данных, отсутствию в них артефактов, чёткой градации прав доступа на уровне транзакции и возможности откатиться на любой момент истории, а так же повышенной отказоустойчивости — добро пожаловать в мир реляционных баз данных. Там уже многие вещи придуманы и продуманы за вас и давно.
И на месте эта технология тоже не стоит. Oracle и Microsoft сейчас предлагают такие вещи, которые ещё лет десять назад казались немыслимыми или невозможными в реализации. Кластеризация? Пожалуйста. Гетерогенный доступ? Возьмите. Работа только с ОЗУ без участия дисков? Вот вам. Куча, куча плюшек прямо с коробки. Не нужно ничего писать руками.
Да, некоторые вещи нужно настраивать и скорее всего вам понадобится специалист соответствующего уровня. Да, некоторые фичи стоят денег и требуют ресурсов. Но одновременно дёшево, качественно и быстро не бывает. Даже с No_SQL. Вы всегда чем-то платите.
Реляционные СУБД — это не SQL-92, который вы учили в ВУЗе (create, alter, drop, insert, update). Стандарты поменялись и обросли фичами.
Напоследок напомню разницу между junior и senior специалистом. Junior отвечает на посталвенный вопрос, а senior говорит «it depends» и уточняет детали. Каждая технология хороша для конкретного случая. Если вам не подходят другие — это не значит, что они плохие. Они просто служат другим целям и подходят под другие требования.

> Почему я не использую реляционные СУБД
> Сейчас мы уже используем Postgres
Расходимся, друзья.

На самом деле вы написали примитивную СУБД под свои задачи, т.к. и задач-то у вас особо нет: 95% всей работы с данными — это CRUD.

Потом вы решите прикрутить кеширование и все закончится тем, что придется писать сложную логику инвалидации кеша. Что уже есть в современных СУБД.

Потом вам понадобится выборка данных с условиями и придется писать код, который будет создавать и поддерживать индексы по всем запросам. Потом вы напишите отдельных сервис, который будет асинхронно пересчитывать индексы. Что уже есть в современных СУБД.

Потом вы захотите отлавливать слишком медленные запросы на выборку данных и вам понадобится логирование. Вы будете прикручивать его где попало, пока не прикрутите везде по умолчани. Что уже есть в современных СУБД.

Затем у вас всплывет проблема дублирования и рассинхронизации данных: когда, например, один и тот же объект-пользователь хранится в 10 местах. Вы придете к тому, чтобы хранить пользователей отдельно, а везде схранить ID-пользователя. Поздравляю, вы изобрели нормализацию данных. Что уже есть в современных СУБД.

Затем вам придется поменять механизм выборки данных, чтобы собирать данные из несольких структур. И вам придется объединять их на лету. Вы только что изобрели JOIN таблиц. Что уже есть в современных СУБД.

После изменения структуры хранимых данных начнутся проблемы с версионингом и придется где-то в письменном виде хранить описание всей структуры данных и всех их типов. Так вы изобретете схемы таблиц и UML.

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

Потом вы решите повзрослеть — выкинуть весь ваш говнокод и использовать любую соверменную беспланую СУБД, которой с головой хватит под все ваши нужны. Потому что незачем писать велосипеды и все, что вам нужно уже есть в куче современных СУБД.

Со некоторыми моментами можно поспорить (но это уже ближе к «халивару»), но в целом статья достойная.
Спасибо автору.

Интересное мнение. Но есть небольшое передергивание. С одной стороны декларируется что все нижеописанное применимо к стартапу — ок. С другой озвученные проблемы РСУБД проявляются при весьма приличном обьеме данных и высокой нагрузке вообще. Что вообще то немного не режим стартапа.
Более того, предлагаемый наколенный велосипед в таких режимах просто не будет работать(В худшем случае разовьется в еще один движок РСУБД). И все.
Ну пару примеров прямо сходу. Банальная необходимость уметь гибко и кастомно искать-сортировать сущности приведет к миллиону мусорных словарей, а по поддержке и рядом не стоит с сиквелом. Необходимость многопоточно обрабатывать одни и тежи данные приведет к походам по граблям с синхронизацией (4 из 5 проинтерьвюируемых мною кандидатов с улицы не могут внятно ответить на вопрос «что такое дедлок»). Ведение статистики сделает велосипедостроение более увлекательным и разнообразным. Про транзакционное изменение нескольких сущностей я наверное не буду и заикаться. Равно как и про параллельную обработку данных кластером из нескольких машин.
Но в целом пожалуй соглашусь: в определенных условиях стартапа или Proof of Concept, низких нагрузках, возможности безболезненно потерять данные, отсутствии требований к транзакционности и все такое — вполне себе рабочий вариант «накидать на коленке».

367 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.
Добавить БД в проект легко. Но потом ее нужно развернуть локально, развернуть в тестовой среде, развернуть на стейджинге, развернуть на продакшене. А это все работа.

может Docker? нет, не слышал...

Oracle в Docker’е. Ага. Разом з RAC, SAN та іншими плюшками...

Да когда же РСУБД уже по-настоящему убьют и я пойду домой...

Ну своя ніша у них завжди буде. Але тренди давно вже інші — db-engines.com/en/blog_post/43

Угу в тренде в своей нише. Построить граф с поиском по динамическим аттрибутам слабо. Так что пока без RDBMS никак

Построить граф с поиском по динамическим аттрибутам слабо.

Это какой-то бред.
Зачем строить граф если он уже есть? Это в RDBMS его надо строить — а в графовой БД просто добавляй узлы и вершины — по мере поступления данных.
Ну а поиск по динамическим атрибутам это просто поиск, просто QL
хотя с учетом того что для вас

доказательства ничего не значат

рассказывать вам что существует жизнь и за пределами RDBMS довольно глупая затея.

Что такое узел? Мне нужно чтобы у вершины были аттрибуты и эти аттрибуты могут изменяться пользователем после построения графа. Например вершина — человек, аттрибуты: возраст, рост, цвет глаз и т.д. Поиск — выбрать всех людей цвет глаз — голубой и рост мейжу 160-180.

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

Есть индексы по таким атрибутам или перебор всего графа?

Есть индексы или их нет — зависит от вас.
Но граф лучше использовать ни когда надо делать выборку из множества — а тогда когда надо делать выборку основанную на связях. То есть если вам важно именно это можете построить связь вида атрибут вершины превращается в ребро графа — и тогда выборка по всему графу будет летать. Прямые руки и голову никто не отменял. Прямолобый индекс-подход как в реляционной моделе — не может без изменений использоваться в других моделях (эффективно). Но это не означает что других моделей эффективных СУБД не существует — просто вы не хотите или вам не нужно в них разбираться вот и все.

В какой графовой базе есть индексы по динамическим аттрибутам вершин? Neo4J нет. Я не утверждал что других эффективных моделей не существует.

Да возьмите тот же janusgraph из опенсорсного например.

А если есть бабло можете и на НЕПТУНЕ амазоновском побаловаться. Там правда индексация скрыта от уровня разработчика но все через multiple labels вскрывается (при желании и необходимости).
Но ещё раз — строить индекс на каждый атрибут поиск по которому может потребоваться в будущем — это не лучший подход (не зависимо от того есть такая возможность в СУБД или нет).

Смотрел Neo4J как самую популярную графовую базу и вот для моего кейса работа с динамическими аттрибутами там через какие-то костыли реализована и индексов нет. На моем кейсе на одной ноде RDBMS уделает ее на раз.
До janusgraph не дошел похоже там есть какие-то индексы, буду смотреть.
Я про индексы в курсе если че 13 лет с базами работаю и просто так на потом индексы не создаю. Есть конкретный кейс графовая структура с динамическими аттрибутами. Сейчас это все в RDBMS и пока по перформансу лучшие результаты.

Neo4J

в последнее время не развивается (а на старте получил популярность за счет хайпа), а

janusgraph

это скорее некий конструктор СУБД — потому как ты там сам выбираешь и настраиваешь хранилище (например кассандра) выбираешь и настраиваешь где будет лежать индекс (например еластик) и все остальное тоже делаешь сам.

Я про индексы в курсе если че 13 лет с базами работаю

Я тоже с базами работаю 15 лет, и я не указываю вам и не советую как конкретно лучше разрулить ваш кейс и что для этого использовать, просто в треде присущи какие-то детско-полярные взгляды (возможно мне так показалось)

Да когда же РСУБД уже по-настоящему убьют

и мне уже более 10 лет смешны холивары скл носкл ибо для каждого конкретного проекта необходим свой набор СУБД с грамотным распределением данных и индексов мужду ними (даже если СУБД одна)
Кстати амазоновский Нептун — еще довольно сырой , хоть мы его и используем — но если знать где он сырой и где его можно и выгодно использовать в проекте, и плотно общаться с разработчиками движка — то сырости станет меньше и задачи будут решены. Правда дорогой зараза — 500$ в месяц базовый инстанс или около того.

Мне нужно чтобы у вершины были аттрибуты и эти аттрибуты могут изменяться пользователем

атрибуты могут не только изменяться но и добавляться (после создания вершины) и разные вершины могут иметь или не иметь разные атрибуты — это только в RDBMS надо знать перечень всех атрибутов (полей) наперед и какой-нибудь запрос на обновление схемы может положить все напрочь.

это только в RDBMS надо знать перечень всех атрибутов (полей) наперед и какой-нибудь запрос на обновление схемы может положить все напрочь.

Это где такому научили? EAV не неслышали

Я знаю что и в RDBMS не обязательно задавать все изначально, это просто ответ на вашу интенцию

Мне нужно чтобы у вершины были аттрибуты и эти аттрибуты могут изменяться пользователем

аля мне нужна база данных и в базе данных должны быть данные и данные могут менятся.

Что такое узел?

это вершина

у вас просто граф неправильно построен «нечистый граф» если вершинами выбрать всё и соотв. «возраст рост цвет» тоже вершины тогда просто по соотв. вершинам строятся индексы и делается выборка вершин по человекам по связям «рост 160» уже тривиальна

by Paul Andlinger, 3 March 2015

свіжак...

а цей графік ваще чудо
db-engines.com/pictures/graph_trend.png

Было 10 юзеров, стало 50 — мегарост же)

свіжак...

Ви зможете загуглити актуальні дані, я в вас вірю.

Никогда. Потому что бизнесу нужны отчеты в виде обычных таблиц — столбцы и строки.

Исходя из моего опыта, почти все Big Data/NoSQL проекты в итоге скатываются к реляционным решениям и SQL. Потому что реляционные базы намного быстрее чем NoSQL и объектные хранилища. SQL, в свою очередь, очень мощный и простой в использовании язык. Если реляционные базы работают медленно, это значит «вы просто не умеете их готовить». Если посмотреть на передовые технологии, то в Hadoop очень популярен Hive (HiveQL), Apache Pig — это sql-подобный язык. В AWS Redshift — это OLAP, Amazon Aurora — это OLTP, Athena — это SQL. Также Redshift имеет возможность читать данные прямо с S3 используя SQL. Метаданные для Hive хранятся в реляционной базе (часто MySQL). Stream Data передаваемая через Kinesis в итоге заканчивает свой путь в Redshift. А все потому, что люди, в итоге, хотят видеть свои данные в виде отчетов, а отчеты — это в основном столбцы и строки. Насчет Reporting Systems — Tableau имеет свое хранилище, которое реляционное. Microstrategy хранит свои метаданные в реляционке.

Исходя из моего опыта, почти все Big Data/NoSQL проекты в итоге скатываются к реляционным решениям и SQL.

Ну наш проект так і не скотився. Зараз ми запускаємо новий для ентерпрайзів, там для сирих time series даних репортінга юзаємо клікхаус.

clickhouse относят к Column-oriented Relational DBMS

правда у неё нет foreign keys и не соответствует acid принципам, но есть sql, данные в виде таблиц с заданной структурой и join’ы (с ограничениями, но есть).
так что да, не ясно, её к умным или к красивым.

но за sql, скорость агрегаций и в целом удобство использования — жирный плюс продукту.

clickhouse относят к Column-oriented Relational DBMS

Дякую, кеп.

но за sql, скорость агрегаций и в целом удобство использования — жирный плюс продукту.

А ще там є компресія. Якої до цих пір немає в жодній класичній реляційці з коробки (привіт постгрес і мускул).

www.altinity.com/...​compression-in-clickhouse

При чому не просто на табличку, а на колонку. + є те саме на рівні драйвера. Нагадаю любителям «сучасних реляціонок», що в постгресі до цього часу немає компресії навіть на рівні драйвера.

Пан теоретик чи пан любе красти? Одна ліцуха ораклава на 1 норм сервер коштує в 10 раз більше ніж ми платим за всі наші ~100 серверів.

Якої до цих пір немає в жодній класичній реляційці з коробки (привіт постгрес і мускул).

Пан мало знає...

Пан не в курсі, що є безкоштовний Оракл...

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

а дальше IPO

Для дева можна. А для прода — ні. Якщо це не так — пруф, будь ласка.

Де-юре вроде как и да, но де-факто
www.oracle.com/...​appdev/xe/faq.html#limits

— 2 CPUs for foreground processes
— 2GB of RAM (SGA and PGA combined)
— 12GB of user data on disk (irrespective of compression factor)

продакшн с такими лимитами, как порш зарезанный до скорости в 20 км/час

О, цікаво, якось пропустив. Доводилось використовувати?

не, только нагуглил из любопытства

Компрессия это да, важно при хранении сотен миллионов и миллиардов событий.
В mysql для нормального сжатия есть archive engine, с партиционированием его ещё хоть как-то можно использовать, но всё равно по возможностям и скорости агрегаций ни в какое сравнение с clickhouse и подобными olap системами не идёт.
А row_format=compressed в innodb всего в 2-2.5 раза размер уменьшает.

Вот такая компрессия www.postgresql.org/...​ocs/11/storage-toast.html ? (Там много всего, но по слову compression находится релевантное)

nosql с вменяемыми агрегациями — это как раз то что надо

В принципе всё равно nosql или нет, лишь бы работало быстро )
Но по итогу для olap нагрузки делаются отдельные продукты (clickhouse, druid, google biq query, amazon red shift и т.д) — с column store схемой хранения и сжатием, для максимального уменьшения количества iops, вставками данных желательно batch’ами, отсутсвием acid и ограниченными возможностями индексирования.

Да вот иногда хочется и не столь монстрообразный column store как big query и т.д.

big query

в общем-то не монструозный, а простой даже по сравнению с clickhouse, но:
* стоит денег за каждый мегабайт обработанных данных запросом (забыл указать ключ партиционирования в запросе, например нужны данные за неделю, а просканило всю таблицу — заплатил лишних денег)
* очень неудобно менять структуру — нет возможности alter’ами удалять/добавлять/менять колонки, можно только незначащую мета-информацию таблицы.

ну, а плюсы — не нужно думать о скейлинге и администрировании

Под попроще я подразумевал нечто вроде mariadb columnstore

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

а так конечно хочется иметь один тул на все случаи жизни )
но, реальность есть реальность, и приходится к базе добавлять redis’ы, кликхаусы, эластиксёрчи/сфинксы и прочие узкоспециализированные штуки.

Ну так и норм когда кликхаус — из пушки по воробьям

Спорить не буду, если производительности хватает под конкретный датасет, то наверное вполне вариант.

А есть личный опыт использования?
Какие-то подводные камни/ограничения/неудобства о чём не пишет документация. Практика использвания всегда интересна.

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

Понял, лет 7 назад для такой-же задачи sphinx использовал. Но сейчас он уже не в фаворе, ES на хайпе.

А вообще кликхаус достаточно простая и удобная штука, имхо (лично мне), проще в использовании чем ЕS. Поставил и не паришься, а оно себе работает, если конечно не нужен full text search (хотя в roadmap’е у них были подвижки и на этот счёт)

случайно наткнулся на github.com/blynkkk/clickhouse4j, значит кликхаус таки зашел :)

А что за BI tool подключили к ClickHouse, если не секрет?

случайно наткнулся на github.com/blynkkk/clickhouse4j, значит кликхаус таки зашел :)

Ну новий проект, нові вимоги до данних. Клікхаус зайшов, бо там є компресія з коробки, що для IoT доволі критично. Рекомендую Вам спробувати цей драйвер. Ми там купу імпрувментів зробили. До речі, з точки зору перформанса в оригінальному драйвері все сумно =).

А что за BI tool подключили к ClickHouse, если не секрет?

В нас все своє. Своя аналітика, репорти і тд.

я с другой планеты, юзаю github.com/killwort/ClickHouse-Net
У меня конкретно только чтение результатов group-by запросов, работает вроде бы хорошо — по бинарному протоколу с lz4 компрессией.

только чтение результатов group-by запросов

А дані далі куди йдуть? На юай?

краткосрочно кешируются и рендерятся во всякие сводные таблицы и JSONы для чартов — собственно SeekTable для подобного live репортинга и предназначен.

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

Со своими тараканами. Когда я написал свои первые селекты, мне тоже казалось, что он простой. А потом мне понадобилось сделать group by, из группы выбрать строку с определённым максимальным значением поля, и тут оказалось, что надо делать два селекта с inner join-ом. Потому что просто MAX(field) взять можно, а остальные поля из той же записи — просто так нельзя.

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

Так хоть group by есть) во многих nosql это только ручками

В XQuery це вирішується легко.

Врешті дійшли й до рекурсивних селектів. І знаєте шо? Воно мені сподобалося :)

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

Миграционные скрипты тоже ОРМ пишет на любой пук?

Миграционный ивент — одноразовое событие в жизни проекта

Так и думал, судя по всему ты до продакшена ничего и не довел.

После фразы выше нету смысла. С тобой все понятно. Удачи.

А навіщо міграція?

Є стартап, він працює, його можна продати. Все, що буде потім — це вже клопіт нового власника. Власник обтрусить з ідеї реалізацію, покличе архітекта, архітект покличе лідів, ліди — сеньйорів, ті — мідлів, мідли — джунів, а джуни — мишок Вєру і Надєжду. І всім кодлом будуть ту рєпку тягнути роками.

Власне кажучи, для стартапа дендрофекальні технології є беззаперечним плюсом. Бо якщо він життєздатний в такому вигляді, то при правильному проектуванні все буде іще краще.

Міграції є, ми їх робим. І вони простіші для нас, оскільки в нас немає БД і нам не треба робити окремо міграцію коду, окремо міграцію БД. Хоча там є свої ньюанси. Про це треба окремий пост.

Если к данным имеет доступ один процесс (может быть сервером) то СУБД не нужно, можно данные хранить в памяти и при изменении сохранять в файлах (даже легко написать процесс отложенной записи в эти файлы). Если к данным должен быть доступ из нескольких процессов, то нужен как-минимум синхронизатор доступа.

Автору респект за гибкий ум. Вы высказали ряд идей, существующих во многих NoSql решениях. Но мне нравится ваш взгляд на их обоснование. Ждите толпы несогласных. Замашки на реляционки на dou привлекают нездоровое внимание местной инквизиции.

Наталия. Насколько я мог заметить, больше всего несогласных было с Вашей фразой

Например, ALTER TABLE выполняется 8,5 часов
Даже я, не будучи чистым middl’ом, серьёзно подумал бы прежде чем запускать такой alter table (а сисадмин точно не позволил бы). И как минимум погуглил бы как можно сделать по-другому.

Хотя в целом ту статью Вашу я поддержал (по своим причинам, не буду повторяться).
А тут у автора вполне обоснованный подход с примером конкретной задачи.
Так что соглашусь, автору респект.
Но при этом также не могу не согласится с Евгением

Если не нужен ACID (атомарность, консистентность, изоляция и отказоустойчивость транзкций) — то реляционная СУБД не нужна.
 и наоборот («наоборот» в оригинале гораздо длиннее расписан).

Для каждой задачи — свои средства. И под какие-то задачи таки лучше подойдёт РСУБД.
Дмитрий Думанский показал для какой задачи (хотя лучше почитать другие его статьи, там подробнее) допустимо другое решение. За что ему спасибо.
А про

нездоровое внимание местной инквизиции
 — не красиво.

Размер базы с тем ALTER был порядка 4 TB. Мидл, не мидл — никто понятия не имеет про контекст этой ситуации, но судить рядятся все. Базу позже перелили на Vertica и все стало ок. Моя фраза про инквизиторов вполне имеет под собой почву.

1. Реляционки живы и будут жить. Будущее за комбинацией баз.
2. Если не знаешь что в конечном итоге это все будет — то лучше брать реляционку.
3. NOSQL вообще очень разные и этот термин не особо что-то значит. Они все ну очень разные.
4. Нереляционные бд (я бы сказал скорее специализированные) стоит брать, когда есть понятие, какой функционал точно необходим, т.к. потом, очень вероятно, его невозможно будет реализовать (операции JOIN примером, или даже может не быть выборок по всем полям и т.п.).

Немного сумбурно вышло.

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

Согласен, но кроме последних двух абзацев и особенно

не читайте этой статьи

Хе-хе, как тут не вспомнить дядю Боба с его примером реального проекта(вики), в котором выбор БД откладывали как только могли, вплоть до сдачи работ заказчику. Который постфактум, оправдываясь очередной «corporate policy» захотел все хранить в базе. И эту фичу они добавили как плагин к релизнутой системе за какое-то смешное время.

www.youtube.com/watch?v=HhNIttd87xs

А так, да — хранили все сначала in-memory, потом в файликах (изменения в вики печально пропадали после ребута)

Так что нечего тут ржать, товарищи :)

100% это оно, спасибо за тайминг — а то мотать/искать этот момент слишком долго

Когда вы запускаете nginx, я запускаю socat!

А кто-то уже даже тушит сервак

... с овощами и прованскими травами

Изложение статьи вкратце: ALTER TABLE выполняется 8.5 часов.

Иллюстрировать утверждение про «субд тратит 90% впустую» ссылкой на статью про какую-то нишевую субд shore — странно

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

підхід багатьох коментучих нагадує
memeguy.com/...re-development-237483.gif
:)

Кому интересно написал продолжение по архитектуре на хабр — habrahabr.ru/post/316370

Мне больше всего понравилось, что вы не использовали Spring. Просто ООП бывает куда лучше чем спринг с его магией, даже если понимать как эта магия работает.

Спринг хорош, но для маленьких проектов — оверхед. Спринг бут тому доказательство.

Спринг бут только кажется хорошим решением, а на самом деле если запустить его с ключем -debug, то становиться видно, что он делает неоправданно много и отключить это тяжело, потому что все автоконфигурации надо отключать вручную, а их по дефолту более 20.
docs.spring.io/...onfiguration-classes.html

Из за чего он и запускается медленно, что приводит к сокращению скорости девелопмента.

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

Каждый раз, когда вы делаете:

user.name = "'Peter'";

Я делаю:
jedis.set("user_name", "Peter"); 
:P

Скорее jedis.hset но это уже извращение.

>Я храню все данные в файловой системе, как простой json файл. Это очень быстро, просто, и это отлично работает.

Дурота. Привет 90-ые. :) А то и раньше.
Или это пост-стеб? :)

А що, треба було для цієї задачі розгорнути RAC Oracle на ASM?

В крайности бросаться не нужно, вот что.

Ага, тобто це вже не дурота... Так, давайте послухаємо думку експерта, як же правильно працювати із json’ами... Ну, Антон, ваше слово.

append only, гениально. Это то, чего всем не хватало. За этой поделкой — будущее. :)
Вперед и с песней, используйте. :)
Не, логи можно писать в текстовые файлы, тут ничего плохого. Но не для чего-то более сложного. Потом захочется навесить туда индексы, шардинг, репликацию, транзакции, группировки, джойны — и получим СУБД. :)
Ладно, в дальнейшем споре на эту тему постараюсь не участвовать. :)

append only, гениально. Это то, чего всем не хватало. За этой поделкой — будущее. :)

Я использую аппенд-онли подход для репортинга. Выглядит на UI так — github.com/...er/docs/overview/dash.png. Пользователи счатливы.

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

Говорил же, что постараюсь не участвовать. Не вышло. :)
Перечитайте первое предложение в третьей строке.

оворил же, что постараюсь не участвовать. Не вышло. :)

:)

Перечитайте первое предложение в третьей строке.

Ну так в этой строчке суть статьи. Если когда-то понадобится что-то еще вроде «индексы, шардинг, репликацию, транзакции, группировки, джойны» тогда СУБД и должна быть добавлена. Но не раньше и точно не потому что «а вдруг пригодится».

Полностью согласен. :)
Я всегда начинаю с простого решения.
Часто функционал настолько усложнился, что потом выбрасывается и эволюционирует в простенький код. :) Это кайф — упрощать код. :)
Если точно известно, что перечисленные вещи из мира реляционок не нужны, тогда ок. :)
Просто у меня в памяти один форумный движок на файлах, которым я пользовался. Ранее, в 2000-ых — это было некоторым преимуществом: можно разместить форум на дешевом хостинге без БД. :)
Но со временем пользователям этого движка захотелось нового функционала, который нереализуем на чистых файлах. А также были проблемы обнулений файлов. :) Развитие движка приостановилось.

А в другой теме мне прозрачно намекнули что у меня SQL головного мозга...

Тут вот какое дело — технические аргументы все стороны исчерпали.

Главный вывод который можно сделать по этому обсуждению — люди отлично понимают про ЧТО, но напрочь не слышат о — ЗАЧЕМ, с какой целью.

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

Но его убеждают что — нет! Оно тебе нужно! Иначе проект загнется!
— но вот я ж и рассказываю на примере проекта, что не загнется...
— он загнется у тебя завтра, потому что тебе понадобятся транзакции, индексы...
— но если мне понадобятся — то я возьму БД с этими возможностями...
— вот видишь! Значит нужно сразу!
— но я ж и объясняю, на примере своего проекта, что не нужно сегодня и сразу то — что может быть понадобится завтра...
— а завтра будет поздно!

И т.д. до бесконечности

Оверінженірінг наше все. Їм страждають багато людей.

Если что-то мне для проекта не нужно, то оно не нужно мне для проекта

Если оно дейтсвительно не нужно, то вопросов нет :)
Просто показалось, что собрались хранить бизнес-данные в чистых файлах. :) Ну, может, там такая специфика, что можно. Но даже для бложика предпочтительнее БД.

Мне так многие доказывают, что нужно использовать фреймворки PHP. :)
А они мне ну нужны.
Кстати, кто какие фреймворки использует на серверной стороне из сторонников простоты? :)

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

А как с этим всем работать? :)
Переизобретать БД? :)
Ну ок, раз в Вашем проекте это оправдано. Используйте.
Только желательно сделайте SQL-интерфейс к своему поделию. :)
Это довольно большой слой работы.
Я сторонник простых решений без стороннего мусора, но СУБД переизобретать не всем оправдано.
Да, мне не нравится наплевательская разработка в mysql, когда баги годами не фиксятся.
Но вряд ли можно это потянуть в одиночку.
Какой размер команды у вас? И сколько человек занимается поддержкой слоя СУБД? :)

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

Переизобретать БД? :)
Только желательно сделайте SQL-интерфейс к своему поделию. :)
файловая система это БД. редис — это БД. монго дб — это БД. и много других БД без скл — зачем его изобретать если он не нужен? если бы был нужен то тогда надо выбирать СКЛ БД.

то что описавает автор, это по сути монга, только в упрощенном виде, ибо ему судя по всему не надо было ее АПИ кроме как записать по ключу, прочитать по ключу — все.

Файловая система в виде текстовых файликов — это БД с натяжкой :)
С таким успехом все файлы — БД. :)
Нужен слой, реализующий поиск/запись/обновление/удаление.
Если это не просто file_put_contents(... FILE_APPEND), тогда это можно назвать самописной БД. :)

Монго и редис поддерживают основной SQL-функционал? Если нет, то им и не нужен SQL-интерфейс. :)

Монго и редис поддерживают основной SQL-функционал? Если нет, то им и не нужен SQL-интерфейс. :)

Монго и Редис не работаю с таблицами и отношениями, они решают свои узко специализированные задачи и делают это более эффективно чем реляционные СУБД. Существует огромное количество структур данных, которые подходят под разные задачи намного лучше чем нормализированные представления в виде таблиц и отношений. Так уже вышло исторически, что много решений делаеться через сложные агрегации, joins, unions таблиц только потому, что это можно сделать. На деле как только инормационная система становиться database-centric, вычислительная бизнесс логика начинает реализовываться оперируя единой структурой данных — таблицей, sql запросы становятся сложнее, нечитабельные и там появляется уйма всяких хинтов и оптимизаций, которые к той самой бизнесс логике не имеют никакого отношения и без которых нередко написать рабочую реализацию бизнес требований становиться невозможным(тот самый велосипед с квадратными колесами) — тем более это свидетельствует, что вы используете реляционные СУБД не по назначению, и ошибочно считаете, что раз реляционные СУБД это поддерживают то с nosql базами или другими структурами данных это сделать будет еще сложней. Все это только потому, что не знаете\можите решить вашу задачу иначе, проще и быстрее, к тому же часто еще и неправильно интерпретируете потребности бизнеса.

Нужен слой, реализующий поиск/запись/обновление/удаление.
зачем, если он уже есть? есть Map<string, userinfo=""> который реализует АПИ и который можно записать в файл и прочитать с файла, в чем проблема?

вообщем рекоммендую вам ознакомится с понятием что такое БД, и какие бывают их виды, и научится определять преймущества/недостатки для того или иного бизнес-кейса

Но даже для бложика предпочтительнее БД.
ЗАЧЕМ? с какой — целью?
собрались хранить бизнес-данные в чистых файлах. :
а чем бизнес-данные отличаются от — небизнес-данных?
из сторонников простоты? :)
простота или сложность это из разряда — ЧТО, КАК.

но вот как и написал:

люди отлично понимают про ЧТО, но напрочь не слышат о — ЗАЧЕМ, с какой целью.

вот судя по ответу вы и так и не врубились что в статье идет речь не о БД, а о том
как из ЗАЧЕМ получать ЧТО, а не наоборот.

Мне так многие доказывают, что нужно использовать фреймворки PHP. :)
задайте им вопрос — ЗАЧЕМ, с какой целью.

и не путайте ответы на вопрос ПОЧЕМУ. Это вторая массовая проблема — люди не понимают разницы между этими вопросами, и на ЗАЧЕМ, отвечают как будто их спросили — ПОЧЕМУ

ЗАЧЕМ? с какой — целью?
Зачем?
Иметь возможность фильтрации по разным полям, выборки по 2-ум и более сущностям, группировки, сортировки... :)
Ваше поделие это умеет? :)

>что, как, зачем, почему
Вы такие вопросы задаете :) Можно мозг вывихнуть в неподготовленном состоянии. :)

вот судя по ответу вы и так и не врубились что в статье идет речь не о БД, а о том
как из ЗАЧЕМ получать ЧТО, а не наоборот.

Правильно, использовать нужно инструмент исходя из задач :)
Я правильно Вас понял? :)

задайте им вопрос — ЗАЧЕМ, с какой целью.
Да, они мне твердят «ПОЧЕМУ» стоит использовать фреймворки. :)
Но при этом моих задач это или не решает или решает дибильным способом.
Поэтому у меня такой вывод, ЗАЧЕМ/ПОЧЕМУ они используют/советуют использовать фреймворк:
потому что они думают: все крутые парни используют фреймворк, это высокооплачиваемо, остальные — лохи
на самом деле: у них скудный кругозор, сведенный до фреймворков, они боятся и не умеют реализовывать каркас, это лишняя ответственность
Ну и приводят кучу натянутых причин, почему стоит использовать фреймворк. :)
Вот есть интересная статья на тему фреймворков:
blog.kpitv.net/article/frameworks-1
Иметь возможность фильтрации по разным полям
зачем? с какой целью нужно иметь такой функционал?
то есть опять та же проблема — вы говорите о ЧТО, о возможностях, а не о цели.
Правильно, использовать нужно инструмент исходя из задач
конечно.
если — НЕ нужна фильтрация по разным полям, если не нужна выборка по двум и более сущностям, если не нужна универсальна сортировка, — то — зачем? на кой?
Да, они мне твердят «ПОЧЕМУ» стоит использовать фреймворки
вот вот. :)

но вы ж тоже начали свой ответ с ответа на ПОЧЕМУ.
а я задавал вопрос о ЦЕЛЕполагании.

Поэтому у меня такой вывод, ЗАЧЕМ/ПОЧЕМУ
зачем и почему — это совсем не синонимы.
Ну и приводят кучу натянутых причин, почему стоит использовать фреймворк.
ну так и сторонники тяжелых решений тоже самое делают.

например почему-то не согласны что «файловую систему» — можно использовать в качестве БД.

я как-то сталкивался с древней, многопользовательской системой где на файловом уровне все было разрулено. Конечно, сейчас именно такую нет смысла создавать. Будет проще взять какую-то существующую БД.

Но, речь то целеполагании как принципе выбора.

Вот есть интересная статья на тему фреймворков:
да, я ее читал.

в ней та же указанная траблема — автор ставит как принцип простоту — а НЕ целополагание.

Еще один выдуманный диалог, я, и некий джун. надо сделать некий нетипичный эл магазин.
Джун:
— А давайте используем Мадженту, она крутая
Я:
— Зачем?
— Ммм.. а, понял, надо вначале что попроще. Тогда Woocommerce?
— Зачем??
— Да, точно, не подумал. Лучше написать с нуля, на Yii2!
— Зачем???
— ...ну-у-у, совсем без Yii2... полностью свой движок?
— Зачем????

Топикастер написал очень толковую статью, и комменты хорошие.
Он раскрыл суть — ЗАЧЕМ он делал так, а не эдак.

Но, джуны все предлагают варианты ЧТО.

И т.д. до бесконечности

Ключевое слово «стартап» не может влиять на выбор БД!

Интересное мнение. Но, вот, как не крути, а если необходимо делать поиск сквозь несколько сущностий, то от RDS мы никуда не денемся! :)

Это можно и на документно-ориентированой структуре данных делать.

а если необходимо делать поиск сквозь несколько сущностий, то от RDS мы никуда не денемся! :)

Можно делать поиск по графу объектов в памяти. При небольших объемах всеравно будет быстрее чем в сеть лезть. Если таких запросов много — то да, лучше БД.

Під статтею з назвою «Чому я не використовую Х» десятки коментарів, як автор пожалкував би, будь в нього проект з реплікаціями, шердінгом, банківськими транзакціями та іншими приємними речами. По осмисленості дії такі коментарі нагадують тих, хто приходять під пости тупих пабліків ВК з цитатами «Джобс любив говорити», і спорять, що імярек сказав цю фразу раніше. Як начебто це оспорює факт, що Джобс промовляв ці слова. Той факт, що в вашому проекті згаданий підхід не спрацював би, жодним чином не вплине, та і не здатний уже вплинути на 2.5 річний досвід роботи сервісу автора без БД. Нам всім доведеться змиритися, що його стартап пройшов первинну фазу виживання без реляційної бази даних, і нести важкий хрест несприйняття далі мовчки і з гідністю.

Когда хостинги были маленькие, многие так вполне работали. Идея не нова ни разу.

Напевне, кожен бачить в чужих словах щось своє. Я не бачу ні предмет для спору, ні нової ідеї. В першому випадку безглуздо спорити з тим, що назване як «чому Я щось роблю чи не роблю», в іншому автор не заявляє, що він придумав щось нове. Напевне, просто нагадування, що можна інакше.

Я не зовсім розумію ідею «не підключайте базу чи редіс, тому що все стане складнішим». Коли я підключаю базу замість підтримки транзакцій на файловій системі, чи редіс замість самописної системи збереження даних по ключах з можливостями редісу, все навпаки стає простіше. Фреймворки роблять роботу простішою, бази даних, редіси, мемкеші, шардінг, реплікація, все робить роботу простішою в ситуації, коли це дійсно потрібно.

Я не зовсім розумію ідею «не підключайте базу чи редіс, тому що все стане складнішим».

Ну так якщо БД спрощує Вам розробку — то підключайте. Я ж не проти :). Для мого випадку це оверхед. В першу чергу через перформанс, в другу через деплоймент процеси. Так як я і розробляю і деплою і моніторю. Цей підхід зберіг мені просто нереальну купу часу.

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

а самопальная сериализация-десериализация

Почему она самопальная? Json.readObject. Json.writeObject. Даже больше. У всех либ джейсонинга есть апи для работы с файлами. Чтобы напрямую писать-читать джейсон в/с файлов.

запись в файлы в фоновом потоке, синхронизация фонового потока с остальными

Это что для БД, что для файлов пришлось бы делать (смотреть пункт 2 статьи).

Почему она самопальная? Json.readObject. Json.writeObject.
А с версионингом ентитей еще не столкнулись? ну ок :)
А бекапы файлов не нужны?
Это что для БД, что для файлов пришлось бы делать (смотреть пункт 2 статьи).
Вам же уже несколько раз указали, даже выше в этом же треде, что рсубд — далеко не единственно возможная альтернатива.
А с версионингом ентитей еще не столкнулись?

Такой задачи нету.

А бекапы файлов не нужны?

Нужны. Так же как и бекапы любой базы.

Вам же уже несколько раз указали, даже выше в этом же треде, что рсубд — далеко не единственно возможная альтернатива.

Вы предлагаете писать в базу (пусть это будет даже редис) на каждый реквест?

Такой задачи нету.
такие задачи имеют свойство появлятсья с течением времени :)
Нужны. Так же как и бекапы любой базы.
бекап базы гарантирует целостность данных. В отличии от простого копирования файлов при рабочем сервисе. Но впрочем это вам не очень надо наверное.
Вы предлагаете писать в базу (пусть это будет даже редис) на каждый реквест?
Я предлагаю использовать встроенные механизмы сохранения, которые можно настроить в конфигах.
такие задачи имеют свойство появлятсья с течением времени :)

О чем собственно и статья. Если бы мы делали продукт исходя из «возможно это понадобится в будущем» то мы до сих пор бы не запустились.

В отличии от простого копирования файлов при рабочем сервисе. Но впрочем это вам не очень надо наверное.

А теперь смотрим в статью и видим, что «Сейчас мы уже используем Postgres (как backup систему)». Хотя основная причина была в том, что бекап диска — дорогая по CPU операция, поэтому пришлось в базу писать небольшимим минутными батчами.

в конфигах

Конфигах чего?

Конфигах чего?
в конфигах редиса, подсказывает кеп.

С реляционными БД все плохо, особенно когда приходишь к тому что БД нужно шарить . А приходит это всегда не к стати. И тогда начинается ЖО** (вот такая да большая и на вчера). Как человек который шарил MySql еще лет 10 тому, могу сказать что не пожелал бы такого экспиренса никому. Так что с того времени только NoSQL, key/value or document oriented DB.

Как человек который шарил MySql еще лет 10 тому, могу сказать что не пожелал бы такого экспиренса никому
что такое «шарить mysql»?

Было бы любопытно почитать, на какие грабли наступать было наиболее больно и как с ними боролись.

Проблемы были на разных уровнях, в конце концов mysql выродился в key/value хранилище когда выборки возможны только по ключевому (причем одному), также для из-за того что 1Гбит сеть начала ложиться между нодами, написали и начали ставить прокси для компрессии запросов к mysql. Потому что CPU дешевый, а сеть очень как легко можно упереться

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

Не знаю на счет мускула, но в постгресе уже пару лет есть компрессия. Правда только для SSL соединений.

Непонятно, откуда такой бешеный трафик: юзкейсы предполагали сбор данных по всем шардам?

Отлично, сейчас есть выбор: mongo/casandra/neo4j, 10 лет тому ничего не было

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

Входящий трафик был большой. А касательно шаринга: соцсети отлично скейлятся по userid. Ну поесть даже простейший crc32(id) будет хорошо работать

А касательно шаринга: соцсети отлично скейлятся по userid
и сценарий «вытащить всех друзей пользователя» приводят к походу по всем шардам :)

Ну не все же так прямолинейно. Никто вот прямо не делает. Все пишется в очередь а очередь уже собирает newsfeed для каждого пользователя, пытаясь еще и группировать события чтоб оно казалось линейно (в порядке от самого нового к самому старому). Проблема в том что люди реально много пишут, много шарят, и все хотят все это увидеть побыстрее.

З.Ы. Я там даааааааавно не работаю :)

ну мой посыл в том, что если возможно, то надо лечить root cause, а именно походы по всем шардам или как минимуму — минимизировать трафик. Охотно верю, что это далеко не всегда возможно, но тут надо в детали копать.

Если пишется очередь, которая потом разбирается — это уже не event sourcing.

Дык, 10 лет тому как бы MySql был мега популярен и альтернатив не так чтоб было много. Только Postgresql or Oracle.
Casandra и всего подобного еще не было, гугл опубликовал свой map-reduce research report как раз где-то в 2006-2007

Да, что значить «шарил MySQL» и что за проект был?

К счастью, не писал соцсети никогда) Тем не менее, я бы лично использовал и реляционный подход (соответственно, реляционную СУБД), и NoSQL, если бы не дай бог пришлось)

Соцсети отлично ложатся на граммовую бд, потому что критично получать нотификации/новости от друзей и друзей-друзей. Но делать тоже самое в реляционной бд это просто самоубийство — слишком много записи, слишком много чтения.

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

Вы сделали рисоварку, без физических кнопок (экономия)
Простите, ничего личного, и без претензий к вашей конкретно компании, но это twitter.com/internetofshit

Тем не менее рынок растет огромными темпами. Одних умных лампочек Hue с вай-фаем (из которых делают потом ботнет :)) за год продали около 1 млн. Можно смеятся, шутить, отказыватся в это верить, называть это — «интернет говна», но это уже происходит.

Конечно, рынок растет. И я не имею ничего против «более умных» вещей, которые тем не менее могут работать в «глупом» режиме. Что мне делать с такой рисоваркой когда вы свернете свой стартап? Как включить стиральную машинку без кнопок если я потерял телефон?

Большинство «интернета говна» сейчас производится ради вау-эффекта, а не для решения конкретных проблем пользователей. Хорошие примеры:

www.youtube.com/watch?v=BpsMkLaEiOY
www.theguardian.com/...-of-tea-with-wi-fi-kettle

Что мне делать с такой рисоваркой когда вы свернете свой стартап?

Продолжать использовать дальше? Она же на блутузе.

Как включить стиральную машинку без кнопок если я потерял телефон?

Как войти в квартиру если Вы потеряли ключи?


Большинство «интернета говна» сейчас производится ради вау-эффекта

Большинство интернета вещей производится из-за реального спроса. И многие людие с радостью выкладывают за это деньги. Вы очевидно не создаете этот спрос. Но это не значит что другим это не нужно.

Небольшой дайджест для тех кто все таки решится использовать БД для аналитики :))

  • ElasticSearch — часто используется для хранения и анализа логов, может принимать на вход тысячи записей за сек, сразу все индексирует, эффективен в distributed режиме. Плюсы и минусы исходят из того факта, что это поисковый индекс на стероидах: фильтрует быстро, агрегирует шустро только если данных после фильтрации немного. Для простой аналитики подходит (статистика, группировки по небольшим периодам).
  • MongoDb — собственно база в интро не нуждается + и — известны; пригодна для моментальной аналитики с оговорками. В отличие от еластика, эффективно может группировать большие коллекции (aggregation pipeline); в действительности real time получается если данных относительно немного (не больше чем RAM), но и в режиме 1:3 показывает приемлимое время исполнения аналитических запросов. Хороший выбор если данные еще не «большие» (не много-много TB). Иногда real time и не нужен, а необходимость ad-hoc запросы есть, и в этом случае монга тоже хороший выбор.
  • MemSql — чистая in-memory SQL DB (не работает если данных больше чем RAM), естественно поддерживет распределенный режим, умеет хранить данные и построчно, и по-колоночно. По одной таблице — реальный real-time, с JOIN-ами как повезет.
  • ClickHouse — новая in-memory SQL DB от Яндекса (держит Яндекс.Метрику), по словам разработчиков уже используется в production в сотне компаний, и вроде бы действительно очень быстрая.
  • MS SQL Server 2016 InMemory — говорят очень быстрая и крутая, но доступна только в Enterprise-edition, ну просто очень дорого :(
А еще бывает так, что данных не так уж и много. И довольно часто бывает :) в этом случае можно обойтись обычной read-only репликой — это легко делается в PostgreSql, MySql/MariaDb, SQL Server. Стоит отметить способ синхронизации — в PostgreSql лог изменений на уровне страниц данных, а в MySql — на уровне команд. При большом потоке изменений (insert/update) PostgreSql может генерить нехилый трафик.

И есть еще одна чудесная БД (встроенная — т.е. деплоймент проще некуда), которая может найти применение во многих случаях: SQLite. Рекомендую обратить на нее внимание во всех случаях, когда данные могут хранится на одном сервере. База невероятно быстрая, умеет вставлять десятки и сотни тысяч записей в секунду (!), поддерживает режим работы «только в памяти», и главное — можно держать для каждого юзера (или SaaS-instance) отдельную базу (=файл), или заводить новую базу по временным периодам (скажем, каждый месяц). Умеет делать запросы сразу по нескольким базам (файлам).

да кстати :) мы разрабатываем продукт для embedded analytics — это .NET Core микросервис (можно хостить на Linux), который коннектится к SQL-совместимой бд (и MongoDb) и предоставляет web API для OLAP запросов и рассчета/рендеринга/экспорта pivot-таблиц, графиков, подготовки данных для BI-дашбордов. Если кому такое надо/есть желание попробовать — обращайтесь в личку :)

MS недавно анонсировали что In-Memory OLTP доступно во всех редакциях, начиная с SQL 2016 SP1. Сам еще не успел попробовать в редакции отличной от Enterprise.

+1 мы у себя пришли к тому что части аналитических задач проще держать копию монги, причем именно копию и сникать ее уже программного раз в 10 минут. Потому что тянуть трафик по 2Тб на ноду выходит — дорого ж блин. Дешевле копия.

На які запити розрахована система? тобто кверяються лише дані по конкретному юзеру? немає щось типу «скільки реквестів зробили юзери в такому то регіоні з такого-то типу девайса в такому-то інтервалі»? і якщо є, то як це вирішуєте?

На які запити розрахована система?

Я думаю найближча аналогія — мессенджер.

тобто кверяються лише дані по конкретному юзеру?

Так, ви логінетись — завантажується ваш профайл.

немає щось типу «скільки реквестів зробили юзери в такому то регіоні з такого-то типу девайса в такому-то інтервалі»?

Є щось схоже — аналог codahale metrics в коді. Є статистика по всім методам і є request rate per user. Статистика реалтайм, без хісторі.

так себе статейка, особенно про «Несерьёзно делать системы, которые умирают при нагрузке в 10 рек-сек.». Про SQL vs NoSql — если вопрос в перформансе то все равно после первого года переписывать придется. В плане сложности и поддержки оба подхода уже достаточно абстрагированы настолько что бы не приходилось вдаваться в детали деплоймента или написание даошек. Складывается такое ощущение что чувак не работал с серьезные NoSQL проектами и не хлебнул там.

так себе статейка, особенно про «Несерьёзно делать системы, которые умирают при нагрузке в 10 рек-сек.»

Наверное вы разработчик таких систем?

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

Будет ли этот проект — dou.ua/...lenta/articles/11k-req-s для Вас достаточно «серьезным»?

Понятия не имею что там ваш проект делал — там про редис 2 строки написано и да я сталкивался с такими системами, ровно как и с такими которые требуют скорости в несколько тысяч ответов за секунду.

Моя мысль была в том, что в общем-то те проблемы которыми вы описали SQL очень просто решаются или вообще решены из коробки(деплоймент мейнтенанс, схема индексы и тд) и не особо отличаются от NoSql. К тому же, например, какую бы технологию вы не выбрали, вам придется где-то хранить схему и индексы(или доп кеши) — либо в самой апе либо в виде структуры стореджа. Вот в плане перформанса конечно у NOSQL явный выигрыш тк нормально запартишинить SQL базу довольно неудобно.

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

Понятия не имею что там ваш проект делал

Ну так по ссылке выше все расписано же.

Моя мысль была в том, что в общем-то те проблемы которыми вы описали SQL очень просто решаются

Ну так если я не буду использовать БД мне их вообще не прийдется решать, понимаете?

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

Почему это вдруг у меня это не укладывается в голове :)? Очень отлично укладывается.

Придется, я об этом и говорю. Хотя все очень зависит от проекта. Вы видимо просто еще не столкнулись с такими ситуациями. Если у вас нету индекса в хранилище — это не значит что вам не придется втулить его на уровне апы. Про схему я вообще молчу — кассандра или монго — там по любому схема будет в том или ином виде и ее надо будет мейнтейнить либо в виде классов либо в виде скриптов и будут все те же стандартные бока только немного в другом месте.

Единственный аргумент в вашей статье с которым я согласен это скорость работы: большинство NoSql пилились с мыслью о производительности, для СУБД же в первую очередь было важно ACID. И тут им нет равных, особенно если говорить про простые key value. Но очень часто за это приходится платить либо упрощением требований либо сложным кодом. Последнее например не всегда приемлемо для стартапов.

Нету проблем с деплойментом, схемой, апдейтами и тд. Если у ни возникают при работы с СУБД и современными фреймворками, то вероятно что-то делается не так. И заменив СУБД на Nosql скорее всего такие же проблемы вылезут где-то на другом уровне. Просто надо понимать реальные отличия и юскейсы и я вам скажу очень мало кто внедрял NoSql только что бы избавится от схемы или упростить деплоймент.

PS. лет 7 назад сталкивался с базой MySql в 20GB положенной на RAMDRIVE — это было в десятки раз дешевле чем нанимать программистов и переписывать на NoSql

тк нормально запартишинить SQL базу довольно неудобно.
Oracle з вами не згодний.

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

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

Но опять же, файловые системы бывают разные. Тот же Гугл не стал изобретать базу данных, но написал свою файловую систему. Иначе говоря, базу данных, которой не нужна нижестоящая файловая система, а просто даётся адресное пространство и делай чё пожелаешь. Те же корпоративные базы данных (в том числе SQL) умеют брать под свои нужды RAW-разделы, и соответственно выступают в роли файловой системы.

В любом случае, реляционки прекрасно выполняют свою роль для структурированных данных. И если проект серьёзный, то как правило есть ОБЕ СОСТАВЛЯЮЩИХ: и база данных для структурированной инфы, и файловая система для не-структурированной. Туда же может добавиться NoSQL если таких данных много, либо же этот NoSQL спокойно ляжет в BLOB-поля, которые сами по себе являются исключением из реляционных правил, и разумеется имеют свои механизмы работы.

В общем, что бы вы ни взяли — так или иначе вы используете огромный труд программистов и сисадминов прошлого. И не надо рассуждать, как всё просто и быстро. «Просто» оно лишь потому, что вылизано и выстрадано, и разумеется расплатились перед взломщиками за все найденные баги.

Кстати, хранить всё в памяти — неразумно. Файловые системы прекрасно кешируются средствами операционки, то есть зачем совать в дорогую память то, что можно положить на SSD? По сути это всего лишь другой тип микросхем той же самой памяти, более выгодно отличающийся стоимостью хранения. Я уверен, в будущем выйдут на коммерческие рельсы и другие типы памяти, которые будут отличаться более высокой скоростью и надёжностью сравнимой с NAND или выше. Они уже разработаны, это вопрос постройки производства.

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

всю статтю можна було замінити на ссилку на вікіпедію KISS — принцип відомий і освітлений обєктивно, на відміну від субєктивної статті автора.

p.s. з нетерпінням чекаю (через якийсь час), серію статей як у людей бомбануло після застосування данної «технології»

а чувак очень прав на самом деле — думаю основной посыл — думайте прежде чем пихать очередную «стандартную» технологию — и он капец как прав, все зависит от реальных требований проекта

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

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

вообщем, как говорил класик: Преждевременная оптимизация — зло.

«Стандартну» технологію пхають не тому, що вона стандартна, а тому що вона універсальна і з часом може витримати всі нові зміни бізнес-логіки та розвиток проекта в цілому.
Але, є проблема в іншому. Вибирають не тільки стандартні технології, а ще й завчені до дірок підходи до самої розробки. Майже всі проекти починаються не з методологій розробки, а з вибору інструментарія: Так, візьмемо RDBMS/NoSQL/XMLDB/..., на BE беремо Spring/Yii/..., з базою спілкуємося через ORM, на фронт ліпимо Angular/React/jQuery й так далі. Знайомий початок проекту?
Наприклад, в мене все абсолютно не так. Клієнти працюють з великими об’ємами даних, для цього краще використовувати SPA (single page application), бо таким чином не треба тягати багато зайвого при переході між сторінками, навантаження на сервер буде мінімальним. Окей, SPA можна побудувати на технологіях: 100% статика завантажується на UI, сервер ганяє тільки дані; рендеринг HTML на стороні сервера, UI тільки отримує готові шматки HTML, або мікс технологій. Обираємо перший варіант як найбільш зручний для всіх підсистем. Необхідно тепер зменшити об’єм статики на клієнті та мінімізувати кількість операцій. Використовувати краще WS, й тут необхідна готовність до максимальної асинхронності. Жоден з фреймворків не задовольняє, пишемо свій, використовуємо FRP. Супер, результат тепер задовольняє на всі 100%. Одну з проблем вирішили, можна йти далі.
Тобто спочатку йде методологія, потім вже підбір інструментів. Якщо методологія розроблена правильно, то можна, наприклад, відкрутити один RDBMS, прикрутити інший, або взагалі NoSQL, і все буде працювати далі без змін.

Как бы вы говорите о том же. Сначала бизнес — потом понимание что для него надо сделать — потом инструменты

Дик не заперечував, доповнював.

Несколько вопросов.

1. Учитывая, что данные кладутся в ОЗУ, а изменения отправлются в БД только раз в минуту, я правильно понимаю, что никакого durability вы не гарантируете?

2. Какая цель распределения системы на 3 датацентра?

3. Как решается вопрос деплоймента (конкретнее — что происходит с содержимым памяти, как восстанавливаетесь после деплоймента, какая длительность простоя?)

4. Можно немного подробнее рассказать о характеристиках аппаратной части, и какой % ресурсов используется?

5. Можно выразить трафик не только в tps но и в mbps?

6. Может ли произойти ситуация при которой за минуту пришло больше изменений, чем вы можете за минуту записать на диск? Как разрулить такую ситуацию?

7. Как отслеживаете изменения данных (конкретнее — как получаете diff который нужно записать на диск?)

Спасибо, хорошие вопросы.

1. Учитывая, что данные кладутся в ОЗУ, а изменения отправлются в БД только раз в минуту, я правильно понимаю, что никакого durability вы не гарантируете?

Так же как и любое приложение которое делает апдейты батчами. Для нас дешевизна решения важнее на текущем этапе.

2. Какая цель распределения системы на 3 датацентра?

Уменьшить латенси в регионах. + как дополнительный бонус распределенность системы.

3. Как решается вопрос деплоймента (конкретнее — что происходит с содержимым памяти, как восстанавливаетесь после деплоймента, какая длительность простоя?)

При kill срабатывает системный хук, который дропает все конекшены и после — сохраняет измененные данные на диск, как это делает 1 мин джоба. При старте сервера все данные вычитываются в память. Рестарт обычно это 5 сек — время прямопропорционально объему данных. Для конечных пользователей вообще не заметно.

4. Можно немного подробнее рассказать о характеристиках аппаратной части, и какой % ресурсов используется?

Расскажу в след статье. В целом 2 vCPU, 2 ГБ RAM один сервер. Текущие сервера нагружены на 10%.

5. Можно выразить трафик не только в tps но и в mbps?

Постоянный траффик ~4Mbps. Так как свой протокол, минимальный пакет 5 байт. С http было бы не меньше 80Mbps.

6. Может ли произойти ситуация при которой за минуту пришло больше изменений, чем вы можете за минуту записать на диск? Как разрулить такую ситуацию?

В теории — да. На рпрактике я разверну более мощный сервер. Чтобы диск перестал справлятся нагрузка на 1 сервер должна вырости в ~100 раз. Даже если такое произойдет с системой ничего не случится, просядет лишь общая производительность системы, так как поток под запись на диск будет много CPU сьедать. Пользовательский network IO будет продолжать работу дальше.

7. Как отслеживаете изменения данных (конкретнее — как получаете diff который нужно записать на диск?)

data.update(value);
data.updatedAt = System.millis();

Спасибо.

Уменьшить латенси в регионах. + как дополнительный бонус распределенность системы.
Какие-то репликации между регионами приходится делать, или данные могут быть изолированы между регионами?

Если данные изолированы, какой план на случай если сервер в одном из регионов упадет? Есть какой-то failover инстанс с живой копией данных?

При kill срабатывает системный хук, который дропает все конекшены и после — сохраняет измененные данные на диск, как это делает 1 мин джоба. При старте сервера все данные вычитываются в память. Рестарт обычно это 5 сек — время прямопропорционально объему данных. Для конечных пользователей вообще не заметно.
Рассматривали риск retry storm при деплойменте? Понимаю, что сейчас вы используете 10% от пропускной способности сервера, но что если штатный трафик выростет, скажем, до 90% от пропускной способности?
Какие-то репликации между регионами приходится делать, или данные могут быть изолированы между регионами?
Если данные изолированы, какой план на случай если сервер в одном из регионов упадет? Есть какой-то failover инстанс с живой копией данных?

Раскажу в след статье, а то уже половину статьи заспойлил :).

Рассматривали риск retry storm при деплойменте?

Я об этом думал и не раз. Так как сейчас «retry storm» я наблюдаю каждый раз при деплое (1500 железяк сразу конектятся после рестарта на 1 сервер). После анализа возможностей тех. стека, что я юзаю, пришел к выводу что ничего плохого произойти не должно при росте.

Так как свой протокол, минимальный пакет 5 байт.
Што? IP-оверхед 48 байт минимум.

IP — 20. Плюс фрейм — 46.

Наверно, имелось в виду, что у TCP — 40, включая IP заголовок. В таком случае это тоже неверно: обычно у TCP сейчас 52, потому что в пакетах идут доп. опции TCP, типа timestamp, а бывает и больше (например, для SACK).
Добавка фрейма уже зависит от транспорта (на дальних линках не Ethernet, а какая-то разновидность SDH, там фрейм меньше).

Это не считая еще DNS, если есть)

Это не считая еще DNS, если есть)

И каким же образом DNS влияет на размер Вашего сообщения?

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

Ну я то в курсе. Вы ответить не под тем постом нажали.

Здесь без разницы, под каким именно (разве что прочтёт не так быстро)

Ви чули про NoSQL? MongoDB, наприклад.

Так, дуже може бути, що ваш велосипед працює швидше навіть за MongoDB (і це буде його єдина перевага), але дуже сумніваюся, що різниця буде така сама, як з SQL базами, а враховуючи копійчану вартість заліза в наш час — дешевше буде докупити додаткове ядро та кілька гігабайтів оперативки, щоб компенсувати ту невеличку різницю, ніж витрачати час на такі велосипеди.

Про які велосипеди мова? Files.write(user.toJson)? Ну давайте тоді і цикли почнемо велосипедами називати.

Ви знаєте яка задача стояла переді мною перед тим як пропонувати мені монгу?

Files.write(user.toJson)?
А читати ви це як потім будете?
Тримаєте всі дані одного користувача в одному файлі і за будь-якої потреби вивантажуєте весь файл в RAM і розбираєте засобами мови?

Ви ж не описали як це все працює, а тільки похвасталися: «замість цього я роблю оце».

Ну й для довідки: Монго безсхемна документоорієнтована база, що зберігає дані в форматі аналогічному json. Все, що можна зробити зберігаючи дані у файлах, можна зробити і в Монго + ще купу всього, чого з файлами зробити не вийде (чи принаймні немає сенсу при здоровому глузді). Тож, якщо ви вважаєте, що Монго вам би не підійшла — ви просто з нею ніколи не працювали (і, мабуть, навіть не намагалися).

А читати ви це як потім будете?

User user = Json.read(path);

Тримаєте всі дані одного користувача в одному файлі

Так.

і за будь-якої потреби вивантажуєте весь файл в RAM і розбираєте засобами мови?

1 раз на початку роботи сервера.

тільки похвасталися

лол


Ну й для довідки: Монго безсхемна документоорієнтована база

Дякую, кеп.

Тож, якщо ви вважаєте, що Монго вам би не підійшла — ви просто з нею ніколи не працювали (і, мабуть, навіть не намагалися).

Ахаха. Може ще щось про мене розкажете?

Ви порівнювали за швидкістю і споживанням ресурсів свій варіант і Монго з ін-меморі сховищем?

І ви так і не пояснили, що такого може ваш варіант, чого не може Монго.

Ок. Спеціально для вас

habrahabr.ru/post/265747
habrahabr.ru/post/231213

Там є багато посилась на почитати. Далі гугл вам допоможе.

P. S. Я працював з монгою достатньо, щоб знати що я ніколи більше її не буду використовувати. (Дивитись посилання вище).

Про Діаспору я колись читав в блозі автора — воно тут взагалі не в тему.

А перша стаття хоч і в тему, але частково там описані недоліки безпосередньо pyMongo (і вони, на жаль, дійсно є), частково вже не актуальна, а решта в основному стосується репліки, якої у вас взагалі нема (або ви забули про неї написати).

Ну, й ніхто не каже, що Монго ідеальна — це просто найбільш універсальний і гнучкий варіант, який добре підійде для більшості стартапів. А далі вже є купа вузькоспеціалізованих БД.

До речі, у статті слід було б змінити назву. Адже ви не використовуєте жодних готових СУБД, а не тільки реляційних. Хоча тема причини не використання інших варіантів в статті не розкрита.

До речі, у статті слід було б змінити назву. Адже ви не використовуєте жодних готових СУБД, а не тільки реляційних. Хоча тема причини не використання інших варіантів в статті не розкрита.
Я уже спрашивал. Молчит автор.
Я уже спрашивал. Молчит автор.

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

Не увидел, хотя и прочитал ещё раз. Зато дартаньянитость из всех щелей.

Зато дартаньянитость из всех щелей.

?

Статья в целом была бы ничего, но тональность pp.vk.me/...0/g1165379/a_8a20765d.jpg

Ви чули про NoSQL?
Лол, зайдіть в профіль Діми тут або на хабрі і почитайте статті які він публікував.

По темі — стаття — вогонь :) Про фронтенд можна так само написати.

Про фронтенд можна так само написати.
у сенсі «нащо вам UI, якщо можна запити через telnet кидати»?

хм. декілька разів стикався з ж «нащо нам той фреймворк, ми нативний js використаємо». а в результаті — саморобний bindToDom, кривий роутінг та навіть власний Bootstrap, з повіями-трансвеститами та «підкидним дурнєм»
Коли хтось каже «нащо мені фреймворк» зазвичай все закінчується розробкой власного :(
а за посиланням висувається висміюється хайп, а не технології, правда ж?

Ты СОВЕРШЕННО не понимаешь в чем суть RDBMS. RDMS это не MongoDB типа «о чуваки зацените как я тремя строчками джаваскрипта вставил документ в базу». Это не псевдоинтеллектуальные обсуждения того, как твитер хранит миллиард новых сообщений. RDBMS это не Cassandra, Reddis или Hbase. RDBMS это место, где DBA могут побыть чудовищами — ужасными, бесчувственными, безразличными чудовищами, которыми они на самом деле и являются.

SQL запрос выполняется три часа, а мы смеемся. Отказало 3 диска в рейде, суточный бекап давно отвалился, а мы смеемся.

Нас заставляют поддерживать базу данных на клипере, работающую с 80 года, а мы смеемся и просим еще. Ненормализованые схемы, хранимые процедуры в 3000 строк, хранение видеофайлов в blob полях — мы смеемся. Разрабочтик дропнул таблицы на продакшене — мы смеемся. Мы бездушно подпишемся под чем угодно, наши предпочтения не основаны на здравом смысле, бесцельные споры — наша стихия, мы — истинное лицо энтерпрайза.

Автор молодец, а по «лучшим» комментам виден «аутсорсинг головного мозга».

Я уже на энном проекте с сиквелом работаю и меня от него тошнит. Типичный «субд» выглядит так — берем любой сиквел (лучше какойнить энтерпрайз эдишн по 10 килобаксов за ядро), напихиваем туда данных побольше — все что у нас есть, пишем кучу stored procedures, храним конфигурацию всех сервисов, создаем табличку со списком валют и стран, а также языков и часовых поясов (а то вдруг надо будет новый часовой пояс добавить!), обязательно должна быть табличка с логами (лучше отдельная база!), конечно же все делаем в третьей нормальной форме (а-ля табличка PaymentType с тремя записями {1, Paypal}, {2, Card}, {3, Cash} которую надо потом джойнить во все запросы), потом реализовываем очередь чего-либо на базе таблицы, потом создаем кучу вьюх, индексов, триггеров, репортов — и побольше всего. Ведь в сиквеле столько фич — он может все! Ах да, я же забыл полнотекстовый поиск и запросы из столбца типа XML... Потом надо обязательно настроить миллиард кривых пермишенов и для полноты картины настоить репликацию и зеркало.

Мне очень жаль что для многих сиквел — это единственная технология которую они знают. Пора открыть глаза и понять что сиквел и б-деревья — это одно из десятков существующих решений для хранения и работы с данными. Людям с тайтлом «архитектор» я бы вообще порекомендовал воздержаться от комментариев в теме чтобы не позорить свой тайтл...

А какие решения для хранения и работы с данными предпочитают современные перспективные разработчики?)

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

Отличный пример с магазином. Вы, когда расплачиваетесь, предполагаете при этом что деньги спишутся со счета ровно в том количестве, на который совершена покупка? Или предполагаете что при этом в некий абстрактный клауд отправится некий поток событий о покупке?)

Вы когда идете в магазин и покупаете товар, врядли продавец думает что ваша покупка должна быть транзакционной
если оплата подтвердится, товар будет выдан, а деньги будут списаны со счета покупателя и не поступят на счет продавца, то я гарантирую что продавцу будет не все равно.
, а данные хранить в клауде
и амазон и ажур предоставляют услуги рсубд(причем амазон — несколько на выбор) as a service.
Но пожалуй на этом фееричном тезисе дискуссию можно заканчивать.

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

и амазон и ажур предоставляют услуги рсубд(причем амазон — несколько на выбор) as a service.Но пожалуй на этом фееричном тезисе дискуссию можно заканчивать.
Да, ажур в этом плане предлагает интересные решения. По крайней мере, интересно заниматься имплементацией «в ажуре») Но по сути, это же просто виртуализация с гарантированной доступностью в случае если приложение/база может обеспечить HA.
Может автор назовет какие-то существующие решения на event sourcing модели, интересно было бы посмотреть.
На самом деле финансовые решения на ивент сорсинге есть. Но они вносят eventual consistency, что в свою очередь приводят к таким интересным вещам как «неразрешенный овердрафт» и массам удивлений у держателей дебетовых карт на тему «как же она ушла в минус и почему я за это должен платить» :)
имха очень даже аргумент не использовать event sourcing, если можно его не использовать.

А есть какие-то эээ, публичные ссылки или сукцесс сториз, так сказать? Ну или может не очень сукцесс, но было бы интересно почитать)

martinfowler.com/articles/lmax.html
пожалуй самая известная
Но любой крупный финансовый интегратор(уже упомянутые мной виза с мастеркардом) так или иначе использует ивент сорсинг, потому что по другому никак.

Интересно, конечно. Как там у визы с мастеркардом, я не знаю, а если речь о процессинге платежной системы, то там обычно на очередях обработка. По крайней мере, те что я видел (понятно, что это был треш и угар, это уже само собой). Конечным пунктом все равно база.

Конечным пунктом все равно база.
event sourcing ваще то ортогонален хранилищу этих самых ивентов. И даже старый добрый transaction log можно с достаточно большой натяжкой назвать event storage-ем :)

С таким успехом можно любой лог назвать построенным по event sourcing модели)
Вот опять же, возвращаясь к процессингу. MQ, RabbitMQ, Tibco всякие — видел. Event sourcing — не видел. Не значит, что такого не бывает, конечно. Не помню чтобы хранилище сообщений в такого рода системах было в базе. Это будет существенно замедлять работу.

Вот опять таки путаница: очереди — это средство доставки(с попутными операциями а-ля фильтрация-трансформация) сообщений компонентам системы. СУБД — одно из возможных мест хранения сообщений.
Активное использование очередей в проекте позволяет говорить о том что в нем event-driven архитектура и не более.
Event sourcing в чистом виде — таки редкий зверек.

Event sourcing — не видел
Коллеги подсказывают что в linkedin чистый event sourcing.

И как это практически реализовано? Каждый раз, как я захожу на свою страницу, разматываются и применяются все события за весь мир?

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

Кэш — значит, малая часть объёма от всего в сумме. И из него вымывается часть объектов по неиспользованию. Иначе это не кэш, по определению.
А при логине заново выполнять многочасовую процедуру сбора текущего состояния (так, вряд ли она займёт при их объёмах меньше нескольких часов).
Значит, что-то не так гладко и, например, есть шардинг. Суббазы на, например, 1/10000 юзеров каждая. Тогда событие «A подружился с B» пишется обоим?
А если одному не записалось? Вот и приехавши.

Ну чисто поговорить.
Во первых кешу совершенно необязательно вымываться; никто не запрещает держать в памяти(локально или распределенно) всю доменную модель.
Во вторых шардинг серверов бизнес логики опять таки ортогонален ивент сорсингу. А вот с

Тогда событие «A подружился с B» пишется обоим?
А если одному не записалось?
неувязочка: в классическом ивент сорсинге это будет одно событие «А подружился с В», в чем собственно говоря и его прелесть. А шардинг можно сделать там по календарным датам к примеру.
неувязочка: в классическом ивент сорсинге это будет одно событие «А подружился с В», в чем собственно говоря и его прелесть.

В чём будет его не прелеssть, а гадоssть. Потому что оно должно индексироваться для обоих. А если событие на троих — то на троих. Конструкция индекса в этом случае (если он есть отдельно — а то event sourcing, в описанном каноническом виде, есть сам по себе индекс) — катастрофически усложняется, до неподъёмности в реальной ситуации (а не в песочнице на 100 записей).

Потому что оно должно индексироваться для обоих.
Не должно, даже более того — «обоих» нет как перситентных сущностей.
катастрофически усложняется, до неподъёмности в реальной ситуации (а не в песочнице на 100 записей)
Выше по треду я приводил урлу на пример высоконагруженной системы построенной на чистом ивент сорсинге. Так что походу его надо попросту уметь готовить.

Господа, давайте не забывать, что в event sourcing’е есть не только write модель, которая, по сути, и представляет собой transaction log из событий «A подружился с Б», но и read модель, которая — суть представление данных, уже оптимизированное для показа на UI. И, довольно часто — денормализованное.

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

Вообще-то думает. «Не отдавать продукт в руки, пока покупатель не выложит на стол деньги». Да, он не употребляет при этом слова «транзакция». Я понимаю, что вы выше всего этого «аутсорсинга головного мозга», но уж хотя бы о том, что транзакции — это не только коммит и роллбэк в СУБД, знать должны были.

Проблема тех кто знает сиквел что для них весь мир состоит из реляционных данных в третьей нормальной форме
Нет. Это проблема вашего восприятия мира и ваших коллег.

навіть якщо продавець про це явно не думає, це ще не означає, що там немає транзакцій. попросіть буханку хліба і не віддавайте гроші — транзакція не завершиться. коли скажете що забули гаманець — буде rollback

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

тежи — это какие? :)
если говорить о платежных системах, то у игроков размера виза-мастеркард нет acid транзакционности. base+eventual consistency, боль та еще, но увы альтернатив не особо.

досвід показує що людей тошнить в першу чергу від того в чому вони не змогли розібратись...

складність розробки схеми для субд — надумана проблема, будь-який no sql можна використовувати як key value storage.

досвід показує що людей тошнить в першу чергу від того в чому вони не змогли розібратись...

Або в чому розібрались повністю в усіх деталях :)

складність розробки схеми для субд — надумана проблема, будь-який no sql можна використовувати як key value storage.

І як перша частина речення повʼязана з другою?

ну вони в різних абзацах навіть... тому більше того що їх відокремлює ніж того що поєднує

dou.ua/...a/columns/dont-use-rdbms
dou.ua/...ta/articles/nosql-vs-sql
кто-нибудь, познакомьте этих двоих — им будет о чем поговорить...

Дум, почти все, кто мог заценить сарказм уже уехали. Ты опоздал на пару лет с вбросом ;)

highscalability.com/...nd-delivers-internet.html
Судя по описанию, вольт вполне может подойти автору.

Ну вот просто не о чем.... точнее о Вашем проекте, архитектура которого для читателей чёрный ящик, либо просто громкий заголовок. Хотите сказать что БД не должно быть панацеей? — можно написать и написано об этом уже много раз проще. Судя по скрину схемы БД, вашему проекту нужно не только хранить данные, но и реализована какая-то бизнес логика, целостность, зависимость, изолированность данных — понимаете о чем я? В любом случае вам пришлось реализовывать эту логику. И судя по всему вы либо исправили вашу архитектуру, что позволило вам обойтись без такой бизнес-логики, либо вы написали куеву тучу лишнего кода и вы очередной кодер которому хочется дать лопатой по рукам. База Данных это не обуза и как вы правильно написали она должна прежде всего дать ответ на запрос, так вот если у вас есть в команде опытный разработчик БД, то он может сделать так как нужно и вы получите результат который нужно уже отобразить, а не получить, а потом ещё в коде обработать. И не злите разработчиков БД когда пишите что 10% тратится на запрос, а все остальное мишура, вы тем самым показываете что ничего не знаете о базах данных.

Если все хорошо работает, финализируйте в продукт, и запускайте. Поклонники импортозамещения все ваши.

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

Вы бы лучше P.S. и P.P.S написали вначале статьи в качестве дисклеймера, так как описаное вами решение подходит только к вашей конкретной задаче на тот конкретный момент времени. Для систем, требующим в определенной степени ACID, это явно не подходит.

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

Ну задач для которых подойдет данный подход много. Так же как и самих подходов :). Вы не поверите, но даже в Киеве есть несколько компаний флагманские продукты которых работают на этом подходе. Для одних это конкурентное преимущество, для других «так проще».

Вы этот тезис используете уже не первый раз. Вы реально считаете, что данное утверждение должно как-то усиливать ваши аргументы?

Да. Именно так новые технологии, подходы обычно проникают в повседневность — на волне успешных применений и success stories.

Охотно верю, что не только в Киеве, но и у того же Гугла есть проекты, где не требуется concurrency, durability, immediate consistency, транзакционность, etc. Об этом стоило бы упомянуть в начале статьи. На счет отсутствия схемы, вы не совсем правы, потому что схема существует всегда: в вашем случае она заменена на формат файла, а также неявно существует в коде.

Подход допустимый если файлы мелкие и их не больше 1000 в папке. Иначе будет не быстрее MySQL на соседнем серваке :)

Из минусов такого подхода: работает только на одном инстансе, при большом трафике потери данных таки будут. Для проекта где меньше 100 пользователй одновременно онлайн, вполне себе решение.

Подход допустимый если файлы мелкие и их не больше 1000 в папке.

Файлов десятки тысяч на одном сервере. Никаких проблем нету. Вычитка пользовательских данных просходит только на старте сервера. Скорость вычитки пропорциональна количеству данных (~5 сек на самом большом сервере).

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

Уже как 8 мес кластер на 5 инстансов. Все в разных датацентрах.

при большом трафике потери данных таки будут

Почему?

Для проекта где меньше 100 пользователй одновременно онлайн, вполне себе решение.

Прямо сейчас на сервере 3000 устройств с keep-alive соединениями онлайн и около 150 пользователей.

Потому что файловая система :)

А если инстансы каждый со своей копией — то это уже нифига не целостная система. Или файлы пишуться только в одном месте?

Потому что файловая система :)

Файловая система понадежней любой СУБД будет.

Или файлы пишуться только в одном месте?

Нет. Файлы это по сути дамп лольного кеша конкретного сервера. По причинам производительности. При старте не надо лезть в сеть, при хранении не надо лезть в сеть.

А если инстансы каждый со своей копией — то это уже нифига не целостная система.

Вполне себе целостная.

Дмитрий Думанский, скажите ваше мнение:
— до скольких одновременных пользователей онлайн выгодно использовать такой подход в стартапах?
— перечислите еще какие условия должны быть по проекту, чтобы применять именно такое решение (а не переходить на любую из типов СУБД) .

Заранее, спасибо.

— до скольких одновременных пользователей онлайн выгодно использовать такой подход в стартапах?

Не знаю. Зависит от проекта. У меня, например, онлайн прямо сейчас 120 человек и 3200 железок и все они в реалтайме пересылают данные и юзеры мгновенно видят апдейты.

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

Нету сложных сортировок, агрегаций, группировок по данным. Если по ключам можно получить все данные которые нужны пользователю, например по его юзернейму.

— я не программист, а игровой продюсер, поэтому уточню: что означает 3200 железок в реалтайме? По вашему мнению, может система держать 1000 юзеров одновременно онлайн скажем в какой-то пошаговой онлайновой стратегии, со средней частотой запросов, например, 1 раз в 10 сек (или все-таки стоило бы уже юзать СУБД)?
//игра простая — будем считать, что все данные юзера хранятся в отдельном save и доступны по ID
— Насчет производительности вашего подхода я почитал в статье. А насколько убыстряется разработка? То есть не получится, что мы пишем по-простому, а потом переписываем уже для СУБД?
— уточню еще больше. Команда занимается потоковым прототипированием небольших онлайн игр. Естественно, что нужно писать быстро и все по 100 раз переделывать пока игра не покажет соответсвующие KPI. Многие из прототипов умирают (70%). Остальные уходят в разработку. Опимально ли в данной ситуации оспользование именно вашего подхода?

что означает 3200 железок в реалтайме?

Это количество одновременных активных соединений.

По вашему мнению, может система держать 1000 юзеров одновременно онлайн скажем в какой-то пошаговой онлайновой стратегии, со средней частотой запросов, например, 1 раз в 10 сек (или все-таки стоило бы уже юзать СУБД)?

Легко. Как раз игры используют такой подход.

А насколько убыстряется разработка?

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

То есть не получится, что мы пишем по-простому, а потом переписываем уже для СУБД?

Не знаю. Зависит от Вашего проекта.

Опимально ли в данной ситуации оспользование именно вашего подхода?

Это Вам решать. Мне кажется — да. Тем более в Киеве 2 конторы как раз так и разрабатывают «онлайн стратегии» :).

Большое спасибо!

Згідно статистики приведеної вами ваш підхід буде працювати у 9/10 випадків. Але це не означає що це панацея. Це означає лиш те, що він є одним з багатьох варіантів вирішення поставлених завдань. Крім того не треба забувати що як раз у тому єдиному випадку ваш підхід може повністю зруйнувати бізнес в той момент коли збільшиться навантаження. Тому що треба буде додавати в терміновому порядку: роботу з базою, міграцію данних, масштабування і зробити доступність сервісу 24/7.

Ваші програмісти витрачають час на написання фабрик, ділять код на слої ітд ітп — вони творчі люди і хочуть реалізувати себе. Хочете отримати той же результат і швидше? Відповідь дуже проста, — найміть людей які коштують дорожче — людей з досвідом, в яких вже є заготовані на чорний день всі ті фабрики і слої, яких ви так боїтесь.

Програмісти діляться на 2 категорії: x) ті хто пишуть код, і y) ті хто пишуть код який можна потім використати багато раз. Набираючи людей які відносяться до категорії «x» — ви спрощуєте собі життя в данний момент (або на поточному проекті, стартапі), набираючи людей які відносяться до категорії «y» — ви спрощуєте собі життя в майбутньому (далекому чи ні залежить вже від вас), тому що з використанням їх коду можна методом copy & paste легко «написати» більшу половину коду для іншого стартапу. І тут вже виникає питання до замовника, — до якої категорії він себе відносить: не вистрілило і здулись чи будемо працювати над іншим...

Звідси маємо наступне: одноразовому стартапу — одноразовий костиль-код, замовнику у якого є багато ідей — багаторазовий код (ну і команди треба підбирати відповідно).

І дайте відповідь на питання, який % коду на поточному проекті ви використали із попереднього ? І скільки зможете використати на наступному?

крім того завжди дивувався коли «бізнес» приходить до розробників і видає «ви нічого не розумієте в розробці, те що ви робите нікому не потрібне, бізнесу треба щоб ви робили щось інше...» — власне це не дивно тому що у 99.9% випадків бізнес й не намагався донести до розробників інформацію про важливість тих чи інших «фіч». Тому, що не міг передбачити важливість тих чи інших «фіч», але чомусь в цьому винні розробники...

З іншої сторони, якщо ви хочете працювати з розробниками, які розбираються в бізнесі, то чому б не наймати саме таких людей: низивайте позиції «Business Development Analyst» а не «developer» і питання вирішене... З іншої сторони, якщо ж ви вважаєте що звичайні програмісти повинні розбиратись у бізнесі то логічно, щоб і бізнес розбирався в девелопменті... підтягуйтесь, вивчіть декілька мов програмування, будуть точніші «estimation» і складність кожної фічі для девелопмента буде одразу зрозумілою...

Во времена 1С 7.7 (2000) таких «уникалов» была целая пачка. Кончилось все тем, что DBF файл после 1GB размера начинал терять записи, и все начали переход на SQL. Основная задача БД это не хранить данные как думает автор, а обеспечить логическую целосность, чтобы нельзя было удалить запись когда есть на нее ссылки в других таблицах. Автор не понимает разницы между ДАННЫМИ и набором записей.

Афтар все понимает, но при больших файлах (или их количестве) все таки может накрыццо медным тазом.

В то время, когда Amazon запускает сервера с 2 ТБ RAM
Простий економічний розрахунок (на рівні математики 2-го класу).
Для того щоб зберегти 2 терабайти даних нам потрібно:
2048/32 = 64 планки памяті по 32 GB
Заходимо на хотлайн і бачимо, що сама дешевенька планка на 32 вартує близько 5 тисяч гривень, тобто нам потрібно 320 тисяч гривень для зберігання 2TB певних даних.
Далі переходимо у розділ HDD і підбираємо дешевенький диск за такими параметрами:
Назначение (для внутренних) для серверов Внутренний интерфейс SAS Размер буфера, МБ
128 и более
І бачимо, що самий дешевий коштує також близько 5 тисяч гривень (Hitachi Ultrastar 7K6000).
Нам потрібно буде таких 2 штуки для дзеркала (5 * 2 = 10 тисяч гривень).
Тобто для зберігання тих самих 2TB певних даних нам потрібно витратити у 320/10 = 32 рази менше коштів.

Це просто приклад тренду. На підході non-volatile memory — наступний логічний крок.

Але ж звичайний HDD і є окремим прикладом

non-volatile memory
Можу навіть спростити для вас умови — і замість SAS взяти Intel DC P3520 2TB який зараз коштує по 35 тисяч гривень за штуку. Навіть якщо взяти 2 штуки, то кінцева ціна буде у 4,5 рази менша порвіняно з ОЗУ.
А у явімо, що ваша система працюватиме не з 2TB даних, а з 120TB... тут навіть Постгре не врятує :)
Тому використання сучасних СУБД = питання суто економічне.

Влад, зачем вы вот это вот здесь делаете? вроде ж не киевский мэр пока. :)
1. Итак, для достаточно интенсивного чтения вам нужна будет ОЗУ размером 30% от размера базы. Разве нет?
2. Даже при ОЗУ и кешировании у вас будет нагрузка. А пардон 1 винт больше 200 иопсов вряд ли тянет. вы уверены, что вам не надо размазывать все это по 20 винтам для нормальной производительности?
пардон, имхо слишком прямолинейный расчет

Влад, зачем вы вот это вот здесь делаете?
Пане Александр.
Я б із задоволенням би відповів на це ваше питання, але довго думав, і до мене так і не дійшов таємний зміст, що вкладений у ці слова :’(

Прошу мене вибачить, але а заглянув до вашого профілю, і побачив там Oracle, MS SQL та ше купу різних страшних термінів. Порівняно із вами, якщо можна так сказати, гуру в кубі — то я зелений джархед... Але ви погоджуєтесь зі мною у тому, що DBMS потрібні, та кількість памяті для роботи з БД може бути у декілька разів менша за обєм даних.

Щодо ваших інших питань, як ви чудово знаєте (пробачте, що нагадую такі банальні речі) розрахунковий обєм ОЗУ це фунція від частоти та обєму звернень. І не можна так однозначно сказати чи це 30% чи інший процент. Для деяких баз потрібен подвійний обєм ОЗУ, і тоді стає правий автор статті.
Трохи вище вашого посту я навів інший пристрій для зберігання даних. Для P3520 виробник заявляє 375000 IOPS на читання та 26000 IOPS на запис. Як ви вважаєете, чи достатньо буде 375 тисяч IOPS для нормальной проізводітєльності?

Для примера вот есть база размером больше терабайта, работает на сервере с ОЗУ 128Г, размер памяти, выделенной для базы, точно не помню, может 90Г.

ну ок, не 256, а 120 Гб. я о том, что считать надо внимательней. :)

Так я к тому что 30% — это подозрительный показатель) Даже для хранилища данных.
Если требовать от заказчиков сервера с несколькими терабайтами для многотерабайтных баз, то можно увидеть вживую как цифры затрат отображаются в округлившихся от офигения зрачках )

Хех, из комментов тут и на фейсбуке узнал, что :

— Я д’Артаньян (ну ок).
— Мой код более чем полностью состоит исключительно из велосипедов и костылей (интересно, кто-то вообще в исходники заглянул?).
— Мой код говно.
— Я говнокодер.
— Наша система это хуяк-хуяк и в продакшн (2 этапа заливки в тест среду и проверок перед деплоем, полное покрытие интеграционными тестами ВСЕХ user stories это, конечно же, не имеет значения, ведь я не использую БД).
— Проект поделка на коленке (пойду скажу клиентам, с миллиоными оборотами).
— Проект не скейлится (текущий кластер в 3-х датацентрах, разве это аргумент).
— Проект скейлится — случайность, повезло, а вот прийдет ынтерпрайз и вы умрете (ну Вам виднее).
— Мне нужны тразнзакции (смотреть ответ выше).

=)))))
Спасибо, что хоть не начали угрожать.

ну и все правильно кроме 2 пунктов

— Наша система это хуяк-хуяк и в продакшн (2 этапа заливки в тест среду и проверок перед деплоем, полное покрытие интеграционными тестами ВСЕХ user stories это, конечно же, не имеет значения, ведь я не использую БД).
— Мне нужны тразнзакции (смотреть ответ выше).
а остальные замечания верны, а оправдания в скобочках, увы, не оправдывают

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

Дмитрий, мы просто Вам завидуем ;-)

Понимаете, Дмитрий, если я возьму какой-нить говнокод на джаве, запощу его сюда и скажу «Из этого следует что джава ниоч))0)», то мне справедливо укажут, что дело не в джаве, а в конкретном куске говнокода.
Вы делаете тоже самое. Я верю вам на слово, что вы втащили проект используя вашу VelosipedDB, я верю вам на слово, что есть норм кейсы, когда ваша VelosipedDB лучше Постгреса. Но этого всего не отображено в вашей статье.

Вместо такого длинного теста можно было написать проще «Здравствуйте, я делаю стартапы и не умею отделять бизнес-логику от прикладной, потому решил не использовать СУБД».

А в бизнесе до 3й-4й версии модели и не понятно где там будет какая логика. Так что еще не известно кто из вас мение синЙор (tm) :)

Вы хоть сами поняли, что сказали?)

С чего были сделаны такие выводы? Разве в ваших приложениях бизнес логика связана с прикладной? О чём вы вообще? Вы когда поектируете приложение вы прежде всего расписываете веб и базу? Или может всё таки нужно начать с бизнес задач и с того что приложение делает? Вот вы по каким материалам учили архитектуру? Из вашего коментария можно заключить что «большие и толстые умные книжки» вы ниасилили. Может хоть видеоролик глянете? Он не большой, меньше часа — как раз вместо сериальчиков под ужин. В этом ролике (ближе к концу) Роберт «Uncle Bob» Мартин, человек с гигантским опытом в нашей индустрии, отец чистой архитектуры говорит о важнейших вещах. Например что база — это деталь, весь подход к хранению данных — это деталь. Да даже web — это деталь. А приложение должно выполнять поставленные перед ним задачи.
А вот и пример использования подхода описанного в этой статье: тоже видеоролик, даже с привязкой ко времени. Суть — авторитетнейшие специалисты в архитектуре в нашей области постоянно откладывали решение о применении базы данных и прочих подходов к хранению данных, просто пользуясь DIP и разграничивая слои. Просто имплементировали бизнес правила — делали приложение что выполняет поставленную задачу. В результате решение привело к лёгкому введению версионирования данных, а когда появился кастомер корпоративная полиси которого предписывала базу — так же легко её имплементили.
Может они тоже не умеют отделять бизнес логику от прикладной — потому не используют базу?
Послушали бы лучше совета да не пороли чуши — не позорили плашку.

Хохочу с вашей способности придумать себе оппонента и с ним отчаянно спорить. Ведь на фоне выдуманного оппонента можно очень лего почувствовать себя умным, верно?

С чего были сделаны такие выводы
Со слов автора
Я не сажусь писать бизнес-логику — я сажусь и описываю мапинг, зависимость между классами и на основе мапинга генерю схему (ну хоть на этом спасибо ORM).
Из этих слов четко следует, что СУБД «мешала» автору писать бизнес-логику, что, собственно, и есть смешно, так как почему-то большинству использование СУБД писать бизнес-логику не мешает. Вот я использую СУБД и спокойно себе пишу бизнес-логику, так как из-за отделения бизнес-логики и прикладой логики никаких проблем с написанием маппинга нету, это и джуну поручить можно. Потому аргумент автора и невалиден — это его личные проблемы, что СУБД ему мешает.

В остальной ваш спор с воображаемым оппонентом я вмешиваться не буду, он достаточно забавен, так что я бы попросил вас его продолжить. Что ж вы сразу с козырей не зашли и гексагональную архитектуру не упомянули, порты, адаптеры, бизнес-логика, как смерть Кащея, посерединке?) Или вместо попсовых роликов не упомянули сразу толстые и умные книжки? Где отсылки к Эвансу, Фаулеру, Вернону?

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

Автор статьи, как мне кажется, имел ввиду

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

а если проект взлетит, все равно лучше переписать
У меня для вас плохие новости — нормально переписать не получится. Вы видели код, который предоставил автор? Посмотрите внимательно на ту часть, где
user.setName("’Peter’«);
userDao.update(user);

противопоставляется

user.name = «’Peter’»;

В первом случае совершается явное сохранение объекта в хранилище. То есть мы вот хотим где-то сохранить объект, неважно, в постгресе, в редисе, да хоть в Кафку отправить, мы его сохраняем. У автора же сохранение совершается неявно, в фоне. Вы представляете, что будет, когда нужно будет прикрутить БД, когда проект взлетит и сколько придется переписать когда, добавляя работу с хранилищем?) А как хэндлить, если я в одних случаях хочу сохранять объект, а в других не хочу?)

Нет, это вы прочитали описание авторского решения и попробовали придумать ситуацию, в которой оно норм. Потому что из авторской статьи совершенно не следует, что именно «для начала» такое решение сойдет.
Вот же, в самом начале
Если вы стартап и начинающий бизнес, то одна из первых задач, которая будет стоять перед вами, — выкатить на вчера хоть что-нибудь. Так как ~90% стартапов умирают в первый же год (цифра 90% разная в зависимости от типа исследования и источника), это требование является довольно разумным и очевидным.
У меня для вас плохие новости — нормально переписать не получится.
Не переделать готовый, а написать новый, под новые сформированные задачи.
Если стартап взлетел, деньги появились, нанимается команда разработчиков, и они начинают параллельно работающему, писать новый продукт. А если не взлетел, то какая уже там разница, как он был написан..
Вы видели код, который предоставил автор?
А аргументы, да, согласен, мягко говоря натянуты за уши..
ы представляете, что будет, когда нужно будет прикрутить БД, когда проект взлетит и сколько придется переписать когда, добавляя работу с хранилищем?)

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

И все же, как хэндлить, когда я в одних случаях хочу сохранять объект, а в других — не хочу?

что значит изменить? У этого класса же есть интерфейс по которому к нему обращаются и получают данные из файла. Вот и создать ещё одну имплементацию этого интерфейса которая будет лазить в базу.

Ну вот, а так хотелось похоливарить.

не упомянули сразу толстые и умные книжки?
Когда-то я говорил что пруфы можно найти у Макконелла, Фаулера, Эванса. Затем стал указывать конкретные их книги. Затем указывал даже со ссылками на разделы. Не работало. После перешёл к ссылкам на статьи в вэбе. Тоже не работало — наверное многабукаф и люди не хотят читать. Тогда пошли ролики и ролики с привязкой ко времени. Если уже и это не сработает — я даже пока не знаю что пользовать вместо.

Все просто — научите ваших воображаемых оппонентов ходить по представленных вами ссылках. Это не сложнее, чем приписывать им те или иные утверждения. Все в ваших руках, дерзайте. ;)

После перешёл к ссылкам на статьи в вэбе. Тоже не работало — наверное многабукаф и люди не хотят читать. Тогда пошли ролики и ролики с привязкой ко времени. Если уже и это не сработает — я даже пока не знаю что пользовать вместо.

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

Кейс с пробкой — годный. Не предполагал такого. Базово думал будут смотреть под ужин вместо сериальчиков. Как читать книги хотя бы во время поездки в метро.

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

Дима, x1.32xlarge стоит где-то 4$ в час, а у вас высоконпгруженная система за 120$ в месяц. Как? Даешь статью об этом. :)

Моя думка наступна: Не використання СУБД в серйозних проектах це просто безпорядок (взагалі інше слово в голові крутиться). Потім після таких стартапів приходиться наводити порядок, розробляти нормальну структуру БД і т.д. PS: дякую вам що ви є, нам буде більше роботи ))))).

Ну это твое личное мнение, когда-то жили вообще без СУБД

Ну, это ваше личное мнение, когда-то жили вообще без электричества...

По-перше, що таке серйозний проект?

По-друге, сходу вигадані контр-приклади серйонзних проектів, де не потрібна СУБД: кешуючий проксі-сервер або програвач відеофайлів.

Ты мои герой, Гарбер©
статья вызывает разные чувства, у кого-то даже разрыв шаблона судя по всему.
но эта штука работает© и, я полагаю, довольно быстро.
автору респект:)

Умилился. Реляционку хоронят уже несколько десятилетий, придумывают очередные костыли, холиварят, бьют лбы. Потом опять приходят к SQL и диву дивуются, как раньше без него справлялись.
На самом деле автор прав. В чём? Если не нужен ACID (атомарность, консистентность, изоляция и отказоустойчивость транзкций) — то реляционная СУБД не нужна. Будет быстрее и проще.
Но если на проекте (стартап это или не стартап) есть чёткие требования по конкурентной обработке данных, отсутствию в них артефактов, чёткой градации прав доступа на уровне транзакции и возможности откатиться на любой момент истории, а так же повышенной отказоустойчивости — добро пожаловать в мир реляционных баз данных. Там уже многие вещи придуманы и продуманы за вас и давно.
И на месте эта технология тоже не стоит. Oracle и Microsoft сейчас предлагают такие вещи, которые ещё лет десять назад казались немыслимыми или невозможными в реализации. Кластеризация? Пожалуйста. Гетерогенный доступ? Возьмите. Работа только с ОЗУ без участия дисков? Вот вам. Куча, куча плюшек прямо с коробки. Не нужно ничего писать руками.
Да, некоторые вещи нужно настраивать и скорее всего вам понадобится специалист соответствующего уровня. Да, некоторые фичи стоят денег и требуют ресурсов. Но одновременно дёшево, качественно и быстро не бывает. Даже с No_SQL. Вы всегда чем-то платите.
Реляционные СУБД — это не SQL-92, который вы учили в ВУЗе (create, alter, drop, insert, update). Стандарты поменялись и обросли фичами.
Напоследок напомню разницу между junior и senior специалистом. Junior отвечает на посталвенный вопрос, а senior говорит «it depends» и уточняет детали. Каждая технология хороша для конкретного случая. Если вам не подходят другие — это не значит, что они плохие. Они просто служат другим целям и подходят под другие требования.

Основная задача СУБД — это не храние, а выборка данных. Отсюда и название SQL — язык запросов. А как выбрать данные из таблицы с десятью миллионами записей без индексов? Да никак.

смотря сколько данных нужно. В этом же и смысл что путь доступа к данным не фиксирован и не нужно каждый раз его пересматривать, это задача СУБД.

А как выбрать данные из 10млн записей в формате json? да также как из бд.Тоесть либо никак, либо если в памяти помещается(кстати, бд тогда тоже выберет без проблем).

На самом деле вы написали примитивную СУБД под свои задачи, т.к. и задач-то у вас особо нет: 95% всей работы с данными — это CRUD.

Потом вы решите прикрутить кеширование и все закончится тем, что придется писать сложную логику инвалидации кеша. Что уже есть в современных СУБД.

Потом вам понадобится выборка данных с условиями и придется писать код, который будет создавать и поддерживать индексы по всем запросам. Потом вы напишите отдельных сервис, который будет асинхронно пересчитывать индексы. Что уже есть в современных СУБД.

Потом вы захотите отлавливать слишком медленные запросы на выборку данных и вам понадобится логирование. Вы будете прикручивать его где попало, пока не прикрутите везде по умолчани. Что уже есть в современных СУБД.

Затем у вас всплывет проблема дублирования и рассинхронизации данных: когда, например, один и тот же объект-пользователь хранится в 10 местах. Вы придете к тому, чтобы хранить пользователей отдельно, а везде схранить ID-пользователя. Поздравляю, вы изобрели нормализацию данных. Что уже есть в современных СУБД.

Затем вам придется поменять механизм выборки данных, чтобы собирать данные из несольких структур. И вам придется объединять их на лету. Вы только что изобрели JOIN таблиц. Что уже есть в современных СУБД.

После изменения структуры хранимых данных начнутся проблемы с версионингом и придется где-то в письменном виде хранить описание всей структуры данных и всех их типов. Так вы изобретете схемы таблиц и UML.

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

Потом вы решите повзрослеть — выкинуть весь ваш говнокод и использовать любую соверменную беспланую СУБД, которой с головой хватит под все ваши нужны. Потому что незачем писать велосипеды и все, что вам нужно уже есть в куче современных СУБД.

Да там всё прекрасно.

Я не сохраняю каждое изменение модели на диск в момент, когда модель меняется. Вместо этого я сохраняю измененные объекты на диск раз в 1 минуту в отдельном потоке.

Еще немного и ребята навелосипедируют Redis например.

Только уже есть Redis 3.2, а у тут после года работы дай бог Redis 0.2 будет.

> Почему я не использую реляционные СУБД
> Сейчас мы уже используем Postgres
Расходимся, друзья.

Это лишь бекап. Бизнес логика работает без БД.

А логика и не должна быть в БД. It depends, но всё же.

А спільнота грішним ділом подумала, що проект почав використовувати готові інструменти, а не писати колеса :)

Значит, у вас нет действительно нужных пользователю данных.

Скажите, а что вы будете делать с данными, если процесс, их содержащий — повис?
Что вы будете делать, если машина, содержащая данные — отключена из-за сбоя, скажем, питания или из-за внутренней ошибки ОС машина ушла в ребут?
Впрочем, ниже, в комментариях Дмитрий Вежнин уже задал много правильных вопросов.
Зачем вам велосипед?

Скажите, а что вы будете делать с данными, если процесс, их содержащий — повис?

Восстановлю при перезапуске из нового процесса.

Что вы будете делать, если машина, содержащая данные — отключена из-за сбоя, скажем, питания или из-за внутренней ошибки ОС машина ушла в ребут?

Подниму другую машину с данными из бекапа.

Зачем вам велосипед?

Нету никакого велосипеда. Он только в воображении комментаторов.

Если вы думаете что БД не крешатся и не херять данные, то у меня для вас плохие новости.

а бекап файла сделать вам регилия не позволяет?

Интересное мнение. Но есть небольшое передергивание. С одной стороны декларируется что все нижеописанное применимо к стартапу — ок. С другой озвученные проблемы РСУБД проявляются при весьма приличном обьеме данных и высокой нагрузке вообще. Что вообще то немного не режим стартапа.
Более того, предлагаемый наколенный велосипед в таких режимах просто не будет работать(В худшем случае разовьется в еще один движок РСУБД). И все.
Ну пару примеров прямо сходу. Банальная необходимость уметь гибко и кастомно искать-сортировать сущности приведет к миллиону мусорных словарей, а по поддержке и рядом не стоит с сиквелом. Необходимость многопоточно обрабатывать одни и тежи данные приведет к походам по граблям с синхронизацией (4 из 5 проинтерьвюируемых мною кандидатов с улицы не могут внятно ответить на вопрос «что такое дедлок»). Ведение статистики сделает велосипедостроение более увлекательным и разнообразным. Про транзакционное изменение нескольких сущностей я наверное не буду и заикаться. Равно как и про параллельную обработку данных кластером из нескольких машин.
Но в целом пожалуй соглашусь: в определенных условиях стартапа или Proof of Concept, низких нагрузках, возможности безболезненно потерять данные, отсутствии требований к транзакционности и все такое — вполне себе рабочий вариант «накидать на коленке».

Необходимость многопоточно обрабатывать одни и тежи данные приведет к походам по граблям с синхронизацией (4 из 5 проинтерьвюируемых мною кандидатов с улицы не могут внятно ответить на вопрос «что такое дедлок»)

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

че сказать то хотел?

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

«Это» — это что?
Я так, на всякий случай напомню о чем был мой пост: я привел набор типичных проблем, которые могут возникнуть при попытке держать в памяти весь набор данных.

Я специально процетировал реплику — паралельная обработка, данных и синхронизация состояния(in memmory). Как часто у тебя возникает необходимость работать строго с одной копией данных — транзакционно писать в нее, ее же читать, да еще и обрабатывать параллельно как-то, как я понимаю, с мутабельностью какой-то да еще и в рамках кластера?
Если ты будет иметь optimistic concurrency на запись, чтение из кеша, и паралельная обработка так же из кеша или другой отстающей копией + optimistic concurrency на запись. Мне интересны примеры какие повседневные задачи бекенд девелопера, это не позволит покрыть и как часто ты их решаешь, что тебе надо все это синхронизировать в реальном времени.

Еще раз:

я привел набор типичных проблем, которые могут возникнуть при попытке держать в памяти весь набор данных
То есть, я такое видел на тех или иных проектах; иногда это приводило к серьезным проблемам. Все. Остальное ты сам сочинил.

То что ты пишешь проблема плохого дизайна в первую очередь. Поменяй дизайн системы и оно так же будет работать In memmory без сложной синхронизации. Если ты решил вместо этого возложить сложную синхронизацию на движок реляционки — оно будет так же лагать, может в других проявления только.

Поменяй дизайн системы и оно так же будет работать In memmory без сложной синхронизации.
Тогда придется бороться за консистентность данных. Или за перфоманс. Или за скорость разработки.
Если ты решил вместо этого сбросить это в реляционку — оно будет так же лагать, может в других проявления только.
Совершенно не факт — просто целый набор потенциальных проблем там решен гораздо эффективней чем это может быть сделано на коленке при разработке бизнес-приложения.
С другой озвученные проблемы РСУБД проявляются при весьма приличном обьеме данных и высокой нагрузке вообще.

Об этом лишь 2 проблемы из 6. Остальные 4 про скорость разработки и простоту системы.

предлагаемый наколенный велосипед

Писать в файл — это типичный инструмент любого программиста, а не велосипед.

в таких режимах просто не будет работать

Это конечно же не так. И блинк это подтверждает (и мы не единственный такой проект, даже в Киеве их хватает).

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

У меня есть статистика. И ничем от codahale метрикс эта статистика не отличается. Никаких велосипедов.

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

У нас, сюрприз, кластер из нескольких машин.

Об этом лишь 2 проблемы из 6. Остальные 4 про скорость разработки и простоту системы.
первые 2 проблемы — тоесть самые важные.
Писать в файл — это типичный инструмент любого программиста, а не велосипед.
зачем писать в файл если можно не писать? :)
Опять таки, с ростом данных тут возможны варианты: «все сразу» в файл все пишется-читается медленно, что надо начинать приседать с загрузкой по страницам, затем с переводом json в бинарку... зачем? Прикрутить какой нить редис быстрее и дешевле.
Это конечно же не так. И блинк это подтверждает (и мы не единственный такой проект, даже в Киеве их хватает).
Вам пока удается удачно ходить между аккуратно разложенными граблями, неоднократно описанных в профильной литературе; тежи рсубд были придуманы как способ борьбы с такими грабляи.
У нас, сюрприз, кластер из нескольких машин.
Если все хорошо шардится — то хорошо. :) Только вот далеко не всегда шардинг возможен.
тоесть самые важные.

Для нашего проекта — да, так как специфика проекта. Текущий блинк кластер может хендлить 40к рек-сек за 120$. Я считаю это круто (будет отдельная статья на эту тему).

зачем писать в файл если можно не писать? :)Опять таки, с ростом данных тут возможны варианты: «все сразу» в файл все пишется-читается медленно, что надо начинать приседать с загрузкой по страницам, затем с переводом json в бинарку... зачем? Прикрутить какой нить редис быстрее и дешевле.

Система оптимизарована для такой работы. Во-первых запись идет только батчами. Во-вторых этим занимается отдельный поток, что не влияет на пользовательский network IO. В третьих мы сжимаем/агрегируем данные, снижая количество на 3 порядка (об этом писал тут — dou.ua/lenta/articles/11k-req-s ) . Так что проблем о которых Вы говорите просто не может возникнуть. Они уже исключены.

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

А я бы сказал наоборот :). Но это уже не предметно.

Система оптимизарована для такой работы.
Просто интересно, не пытались ли прикрутить готовый кешинг, умеющий персистать данные в файл: редис, коучдб, мембейс какой нить? Если пытались — то почему не взлетело? А если не пытались — то посмотрите в это степь, может пригодиццо.

Использовал на других проектах. Но зачем мне тут кеш, если у меня все данные и так в RAM?

Чтобы писать меньше кода.

Так в этом то и прелесть подхода без БД. Вы лишь фокуситесь на бизнес логике. Рекомендую заглянуть в ссылку на гитхаб проекта.

работа с файлами, в отдельном потоке, с синхронизацией — это не бизнес логика. Это уже реализовано 100500 раз в том числе и в кешинг движках. Я бы это зареюзал.

редис
Redis уже давно не умеет ничего никуда персистить.
У меня есть статистика. И ничем от codahale метрикс эта статистика не отличается. Никаких велосипедов.
скажем так, аналитики и репортинга (ad-hoc запросов и агрегаций) по всем накопленным данным сейчас нет — и если не нужно, наверно повезло :-)
У нас, сюрприз, кластер из нескольких машин.
насколько я понимаю, данные просто шардятся, никакой распределенной обработки нет — и в этом тоже повезло. Как только появится жирный клиент, все данные которого не умещаются на одной машине, с файликами прийдется завязывать...
Аптайм 99,99% за полтора года.
так я вам скажу, что прямо сейчас тот самый 0.01%
internal error — server connection terminated
Description: internal error — server connection terminated

Вы куда-то не туда конектитесь или не тем.

Я просто пошел по ссылке с вашего профиля. Вот попробовал еще раз только что.

Но да, если не вести логов(бесполезная трата ресурсов!) и на все вопросы отвечать «Вы куда-то не туда конектитесь или не тем», то можно и до 100% аптайм довести.

Удачи.

Ну я на всякий случай уточню — у нас нету веб интерфейса. Так что мне остается лишь гадать о чем Вы.

А, ну это многое объясняет. Непонятно, правда, зачем вы у себя в профиле и в конце статье("О проекте) дали ссылку на сайт, у которого нет веб интерфейса, но это уже незначительные мелочи.

А, я понял о чем Вы. Вы о blynk.cc. Это просто лендинг пейдж, который даже не у нас хостится, а у сервиса конструктора сайтов. У меня открывается. Они бывает падают, да. Для нас это не критично, так как нас находят в основном через google play.

ви дєлаєтє так... а я дартаньян

Можете расказать подробнее про Postgres (как backup систему)? В сравнении с mysql или другой субд.

Система высоконагруженная, поэтому делать бекапы диска раз в день — накладно по ресурсам (много CPU кушает). Вместо копировать диск, решил просто изменения апдейтить батчами в базу. В базе есть несколько отдельных таблиц. Пользовательские профайлы хранятся как key-value (чтобы не заморачиватся со схемой). Репортинг данные нормализированные. В целом данные в БД только пишутся. В нормальном сценарии все данные читаются из машины к которой подлючен пользователь. Без раундтрипов по сети за данными.

Спор Postgres vs mysql как по мне не имеет смысла. Довольно близкие системы по функционалу. Берите то, что больше нравится.

Похоже на бекапы журналов транзакций и delayed durability в MS SQL Server.

Дима, а что вы используете для репортинга? Юзера же какие-то дашборды наблюдают по всем этим данным с девайсов? Вероятно, какая нибудь монга (еластиксерч, или может даже яндексовский ClickHouse) все равно понадобится.

Использую подход из предыдущего проекта. Ужимаем данные по минутам. Например, если в течении минуты пришло 5 значений, то в файл сохряем 1 усредненное значение (так как платформа долгое время была бесплатной, экономили на всем). Храним просто в файле, как

github.com/.../ReportingWorker.java#L57

Фильтров по времени нету. Выводим просто Х последних значений. Выглядит так :

github.com/...er/docs/overview/dash.png

Потребности группировать по разным измерениям нет? Или юзерам такое не надо — посчитать там мин-макс-среднее-stddev по девайсам, отфильтровать, по году-месяцу-дню (не знаю какие еще атрибуты там могут быть).

Потребности группировать по разным измерениям нет?

Нету. Единственная группировка, что есть — это по временным интервалам. Делаем это наперед, во время записи в файл.

Или юзерам такое не надо — посчитать там мин-макс-среднее-stddev по девайсам, отфильтровать, по году-месяцу-дню

В большинстве своем досточно графика, что в коментарии выше. Основные жалобы — график маленький. Будем увеличичвать на мобайле + планируем добавить кибану для веба.

А там де Kibana — там і ElasticSearch піде, будуть дані зберігаться по time-frame і індекси додадуть швидкодії для вибірки статистики.

Со некоторыми моментами можно поспорить (но это уже ближе к «халивару»), но в целом статья достойная.
Спасибо автору.

Підписатись на коментарі