Думаю, первыми под удар попадут владельцы тех сервисов, чьи выходные ip были обнаружены отечественным софтом, получившим апгрейд по методичке минцифры.
Спасибо. В свое время сильно огреб, используя массивы. С точки зрения хранения и выборок все было идеально. Типизированные массивы, индексы 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 фреймворков. Вот это та часть, которую как раз интересно было бы узнать в продолжении.
Зарегистрировался только сегодня, чтобы поставить плюс этой статье.
И отдельно спасибо за упоминание слова "этичность". Вижу, как в последние годы эта сущность постепенно покидает чат. Надеюсь, однажды этот тренд развернется, но сначала должна в полную силу проявиться "трагедия общин" на поле рекламы, удержания внимания за счёт манипуляций и и.д.
точно, опечатка по Фрейду вышла
Говорят, там выпили чаты для пользователей из РФ.
Вилимо, Телеграму это же предлагается.
Думаю, первыми под удар попадут владельцы тех сервисов, чьи выходные ip были обнаружены отечественным софтом, получившим апгрейд по методичке минцифры.
Или владельцы коммерческих vpn.
Можно вместо второго внешнего vps пустить трафик через cloudflare warp.
Добавлю, что сам рустор тоже.
Спасибо. В свое время сильно огреб, используя массивы. С точки зрения хранения и выборок все было идеально. Типизированные массивы, индексы 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 фреймворков. Вот это та часть, которую как раз интересно было бы узнать в продолжении.
Читаю хабр много лет.
Зарегистрировался только сегодня, чтобы поставить плюс этой статье.
И отдельно спасибо за упоминание слова "этичность". Вижу, как в последние годы эта сущность постепенно покидает чат. Надеюсь, однажды этот тренд развернется, но сначала должна в полную силу проявиться "трагедия общин" на поле рекламы, удержания внимания за счёт манипуляций и и.д.