Спасибо. В свое время сильно огреб, используя массивы. С точки зрения хранения и выборок все было идеально. Типизированные массивы, индексы btree_gin. Проблема мы начались на проде, когда выяснилось, что данные сильно неоднородные (массивы от 1 до 1_000_000 элементов), и процентов 30 из них перезаписывается каждую ночь. В одну из таких ночей положил кластер, поскольку кончилось место на диске: WAL сожрал всё.
В итоге пришлось откатиться до решения с россыпью отдельных строк. Было красиво, но в сценарии с длинными массивами и частой перезаписью это не подходит, о чем вы и пишете в статье.
Спасибо вам за такое детальное расследование и вашу принципиальность. Вспомнил одну историю.
Дважды встречал подобную схему пару лет назад, когда покупал пылесос, только у других продавцов. Один раз в РБТ - там удалось вовремя заметить и послать их. Второй раз в МВидео - после покупки я оказался удивленным обладателем ещё и какой-то ерунды с невнятной формулировкой тысячи за 2-3, точную сумму уже не вспомню. Естественно, ни в каких документах о покупке она изначально не фигурировала. Формальную возможность вернуть деньги оставили, максимально трудоемкую и неудобную. Из принципа прошел этот квест до конца, деньги вернул, но боюсь даже представить, сколько людей на это просто забили.
Написал обращение вроде бы в Роспотребнадзор и куда-то еще, итогов не знаю. Скорей всего, никаких.
К чему я все это рассказываю. Я бы с удовольствием оставил эти 2-3 тысячи тому, кто грамотным юридическим языком и законными способами поставил бы всю эту контору в коленно-локтевую позу. Подобные услуги мне известны в двух сферах: автоюристы, которые судятся со страховыми за процент от отвоеванной суммы, и юристы по приемке квартир у застройщика. Про первых не знаю практически ничего, но вот вторые вроде бы неплохо зарабатывают, хотя и перегибают палку в противоположную сторону.
В общем, оставлю здесь мысль, что на борьбе с такими схемами теоретически можно было бы зарабатывать. Вряд ли это свежая идея, но пусть себе индексируется и однажды доберется до въедливого и предприимчивого юриста.
А вот как ваши гениальные идеи реализуются на стороне клиента.
Я стою на заправке, мне надо перевести деньги между своими счетами. Захожу в приложение банка, собираюсь перейти в раздел с переводом. В этот момент выскакивает модалка с очередным "уникальным персонализированным приложением". Вместо нужной мне кнопки я жму долбаную рекламу, меня перекидывает в браузер, там начинается отдельный процесс. На улице минус тридцать, и попробуйте предположить, чего в этот момент я желаю маркетологам, придумавшим этот гениальный ход.
За те 15 лет, что я работал с 1С, примерно каждые год-два появлялись все новые и новые "убийцы 1С".
Вообще я за то, чтобы в этом сегменте было больше одного крупного игрока. Чтобы была честная конкуренция и более динамичное развитие.
Но, увы, этого до сих пор не произошло, по разным причинам. 1С действительно хороша для своих задач. Я сомневаюсь, что предложенное решение в части хранения данных способно составить конкуренцию хотя бы по техническим параметрам (лёгкость поддержки, скорость работы).
Визуальная работа с сущностями, которую вы описываете - это классная вещь, тут плюсую. Но когда дело доходит до чуть более сложных бизнес-правил, то всегда в конце концов приходится писать код. И выигрывает здесь тот, кто сделает эту часть максимально лаконичной и близкой к бизнес-задаче, чем к техническим деталям вроде индексов БД и выбору между массивом и хэш-таблицей.
В 1С ведь есть подобные визуальные конструкторы, вроде конструктора проводок или конструктора отчётов. Но они годятся только для прототипа либо демонстрации возможностей на учебном курсе.
Так что цель и правда выглядит амбициозной, но для ее достижения, на мой взгляд, нужны другие технические решения.
Я к этому и веду. Какой уровень изоляции в транзакции?
Предполагаю, исходя из строения таблиц, что транзакции будут блокировать таблицу практически целиком. Т.е. система рассчитана на очень небольшое количество транзакций, что соответствует скорее малому бизнесу или прототипу. С повышением нагрузок на запись могут начаться проблемы. Исследовали ли вы уже этот вопрос? Может, у вас уже есть решение.
Если состав бизнесовых сущностей до конца не определен, то один из классических способов - использовать NoSql БД. Ну или тот же самый постгрес с JSONB. Там и индексы можно накидывать в том числе, и транзакции более явные делать. Смотрели ли в эту сторону?
Если я правильно понял идею, то она заключается в следующем. Например, есть сущность "клиент" с полями: Название, ИНН, КПП. В классическом sql это будет 1 запись в таблице с 3 колонками (плюс четвертая - id). В Ideav это будет 3 строки в таблице с колонками: entity-key-value.
Если так, то как будет выглядеть, например, запрос вида "покажи все остатки товаров на складе в разрезе партий,по которым они пришли"? Или "дай список товаров, которые не продавались более трёх месяцев"?
Хорошо, оба с фронта одновременно начали делать бронь и у обоих это удалось. Такое возможно? Если нет, то за счёт чего, какая там механика под капотом?
Например, расскажите о реализации блокировок в Ideav. Классическая ситуация: 2 клиента одновременно видят один последнее яблоко на товарных остатках и хотят его купить. Кому из них достанется яблоко? Если только одному, то за счёт чего это будет реализовано?
Также интересно узнать, что приходит на замену сложным join'ам в аналитических отчётах.
Из того, что мне встречалось, самый удобный мостик между языком бизнеса и разработки предоставляет платформа 1С. Не все идеально, но тот подход выглядит гораздо более жизнеспособным, чем описанный в данной статье. Впрочем, ИМХО.
Возможность декомпозиции. При этом результат будет представлять единый юнит, а не россыпь разрозненных функций, гоняющих между собой набор одинаковых параметров.
Возможность применения DI фреймворков. Вот это та часть, которую как раз интересно было бы узнать в продолжении.
Зарегистрировался только сегодня, чтобы поставить плюс этой статье.
И отдельно спасибо за упоминание слова "этичность". Вижу, как в последние годы эта сущность постепенно покидает чат. Надеюсь, однажды этот тренд развернется, но сначала должна в полную силу проявиться "трагедия общин" на поле рекламы, удержания внимания за счёт манипуляций и и.д.
Спасибо. В свое время сильно огреб, используя массивы. С точки зрения хранения и выборок все было идеально. Типизированные массивы, индексы btree_gin. Проблема мы начались на проде, когда выяснилось, что данные сильно неоднородные (массивы от 1 до 1_000_000 элементов), и процентов 30 из них перезаписывается каждую ночь. В одну из таких ночей положил кластер, поскольку кончилось место на диске: WAL сожрал всё.
В итоге пришлось откатиться до решения с россыпью отдельных строк. Было красиво, но в сценарии с длинными массивами и частой перезаписью это не подходит, о чем вы и пишете в статье.
Спасибо вам за такое детальное расследование и вашу принципиальность. Вспомнил одну историю.
Дважды встречал подобную схему пару лет назад, когда покупал пылесос, только у других продавцов. Один раз в РБТ - там удалось вовремя заметить и послать их. Второй раз в МВидео - после покупки я оказался удивленным обладателем ещё и какой-то ерунды с невнятной формулировкой тысячи за 2-3, точную сумму уже не вспомню. Естественно, ни в каких документах о покупке она изначально не фигурировала. Формальную возможность вернуть деньги оставили, максимально трудоемкую и неудобную. Из принципа прошел этот квест до конца, деньги вернул, но боюсь даже представить, сколько людей на это просто забили.
Написал обращение вроде бы в Роспотребнадзор и куда-то еще, итогов не знаю. Скорей всего, никаких.
К чему я все это рассказываю. Я бы с удовольствием оставил эти 2-3 тысячи тому, кто грамотным юридическим языком и законными способами поставил бы всю эту контору в коленно-локтевую позу. Подобные услуги мне известны в двух сферах: автоюристы, которые судятся со страховыми за процент от отвоеванной суммы, и юристы по приемке квартир у застройщика. Про первых не знаю практически ничего, но вот вторые вроде бы неплохо зарабатывают, хотя и перегибают палку в противоположную сторону.
В общем, оставлю здесь мысль, что на борьбе с такими схемами теоретически можно было бы зарабатывать. Вряд ли это свежая идея, но пусть себе индексируется и однажды доберется до въедливого и предприимчивого юриста.
А вот как ваши гениальные идеи реализуются на стороне клиента.
Я стою на заправке, мне надо перевести деньги между своими счетами. Захожу в приложение банка, собираюсь перейти в раздел с переводом. В этот момент выскакивает модалка с очередным "уникальным персонализированным приложением". Вместо нужной мне кнопки я жму долбаную рекламу, меня перекидывает в браузер, там начинается отдельный процесс. На улице минус тридцать, и попробуйте предположить, чего в этот момент я желаю маркетологам, придумавшим этот гениальный ход.
За те 15 лет, что я работал с 1С, примерно каждые год-два появлялись все новые и новые "убийцы 1С".
Вообще я за то, чтобы в этом сегменте было больше одного крупного игрока. Чтобы была честная конкуренция и более динамичное развитие.
Но, увы, этого до сих пор не произошло, по разным причинам. 1С действительно хороша для своих задач. Я сомневаюсь, что предложенное решение в части хранения данных способно составить конкуренцию хотя бы по техническим параметрам (лёгкость поддержки, скорость работы).
Визуальная работа с сущностями, которую вы описываете - это классная вещь, тут плюсую. Но когда дело доходит до чуть более сложных бизнес-правил, то всегда в конце концов приходится писать код. И выигрывает здесь тот, кто сделает эту часть максимально лаконичной и близкой к бизнес-задаче, чем к техническим деталям вроде индексов БД и выбору между массивом и хэш-таблицей.
В 1С ведь есть подобные визуальные конструкторы, вроде конструктора проводок или конструктора отчётов. Но они годятся только для прототипа либо демонстрации возможностей на учебном курсе.
Так что цель и правда выглядит амбициозной, но для ее достижения, на мой взгляд, нужны другие технические решения.
Что ж, это будет работать в определенных ограничениях, но когда эта абстракция протечет, спускаться на уровень ниже будет больно.
Я к этому и веду. Какой уровень изоляции в транзакции?
Предполагаю, исходя из строения таблиц, что транзакции будут блокировать таблицу практически целиком. Т.е. система рассчитана на очень небольшое количество транзакций, что соответствует скорее малому бизнесу или прототипу. С повышением нагрузок на запись могут начаться проблемы. Исследовали ли вы уже этот вопрос? Может, у вас уже есть решение.
Если состав бизнесовых сущностей до конца не определен, то один из классических способов - использовать NoSql БД. Ну или тот же самый постгрес с JSONB. Там и индексы можно накидывать в том числе, и транзакции более явные делать. Смотрели ли в эту сторону?
Если я правильно понял идею, то она заключается в следующем. Например, есть сущность "клиент" с полями: Название, ИНН, КПП. В классическом sql это будет 1 запись в таблице с 3 колонками (плюс четвертая - id). В Ideav это будет 3 строки в таблице с колонками: entity-key-value.
Если так, то как будет выглядеть, например, запрос вида "покажи все остатки товаров на складе в разрезе партий,по которым они пришли"? Или "дай список товаров, которые не продавались более трёх месяцев"?
Возможно, я просто не так понял вашу идею.
Хорошо, оба с фронта одновременно начали делать бронь и у обоих это удалось. Такое возможно? Если нет, то за счёт чего, какая там механика под капотом?
Например, расскажите о реализации блокировок в Ideav. Классическая ситуация: 2 клиента одновременно видят один последнее яблоко на товарных остатках и хотят его купить. Кому из них достанется яблоко? Если только одному, то за счёт чего это будет реализовано?
Также интересно узнать, что приходит на замену сложным join'ам в аналитических отчётах.
Из того, что мне встречалось, самый удобный мостик между языком бизнеса и разработки предоставляет платформа 1С. Не все идеально, но тот подход выглядит гораздо более жизнеспособным, чем описанный в данной статье. Впрочем, ИМХО.
У класса есть как минимум 2 преимущества:
Возможность декомпозиции. При этом результат будет представлять единый юнит, а не россыпь разрозненных функций, гоняющих между собой набор одинаковых параметров.
Возможность применения DI фреймворков. Вот это та часть, которую как раз интересно было бы узнать в продолжении.
Читаю хабр много лет.
Зарегистрировался только сегодня, чтобы поставить плюс этой статье.
И отдельно спасибо за упоминание слова "этичность". Вижу, как в последние годы эта сущность постепенно покидает чат. Надеюсь, однажды этот тренд развернется, но сначала должна в полную силу проявиться "трагедия общин" на поле рекламы, удержания внимания за счёт манипуляций и и.д.