Comments 39
Определенно - ТОРТ 🎂... Но переварить его будет трудно.
В самом начале обещали фундаментальную теорию. Кроме теорем CAP (доказательства которых не приняты значительным количеством специалистов, да и собственно говоря теоремами они и не являются - скорее предположениями), фундаментальных основ не предложили, было бы конечно интересно. Потому как всё, что в статье написано действительно известно и используется, но в сфере вычислительных систем, а хотелось бы обоснованных определений, что такое данные и их обработка за пределами узкой направленности, которую вы разложили.
всё, что в статье написано действительно известно и используется
Можно ссылку, где используется? Не хотелось бы изобретать велосипед.
Так у вас каждый раздел начинается со ссылки либо на существующее определение, либо на существующие разработки. И материалы по ссылкам вами никак не анализируются на предмет годности/негодности, а просто берутся за основу повествования в каждой главе.
Как бы новизна обычно преподносится ортодоксальным и испытанным способом: проблематика - анализ существующего - цель - новизна - оценка предполагаемого/достигнутого результата.
У вас эта привычная последовательность отсутствует, поэтому весьма трудно и оценивать ваш материал.
Для тех, кто подобно автору чего-то не знает, но хочет узнать от других.
Не надо выкладывать сразу всё. Знающие люди перестанут читать после первой-второй глупости, поэтому ваш выстрел станет холостым.
Не надо выкладывать свои теории в той области, про которую мало знаете. Это ещё сильнее оттолкнёт знающих.
Предложения вроде "я тут составил классификацию..." опять же должны остаться с вами, потому что в той области, в которой вы плохо разбираетесь, ваша классификация будет лишь напоминать знающим специалистам о бесполезности разговоров с вами.
Учитывая выше сказанное, автор совершил все ошибки, какие только можно совершить. Предполагаю, он ожидает от комментаторов вдумчивого и глубокого ответа, учитывающего чувство собственного величия автора, ну и прочие моменты, имеющие своей базой психологию. Но вспомнив про ошибки, мы все понимаем, какой уровень психологического комфорта ожидает автора. Поэтому ещё один совет:
Не нужно выставлять себя специалистом в той области, в которой вы не специалист. Даже если в какой-то другой области вы что-то понимаете. Ведь вы пришли в чужой дом, а не к вам пришли за помощью.
Но есть всё же важный момент вокруг затронутой автором темы помощи начинающим.
Как начинающему запросить плодотворную дискуссию?
Автор попытался сделать это при помощи упора на свой авторитет, для подтверждения которого привёл свои наработки. Наработки, правда, оказались на уровне, скажем так, привычном для писателей книг из серии "Искусство очень умных разговоров на технические темы", что несколько ниже ожидаемого экспертами уровня. Значит участвовать эксперты не будут. Хотя можно привлечь много юных дарований, которые очень даже считают себя экспертами. Но нужно ли это автору?
Теперь позитивные подсказки.
Располагайте к себе аудиторию. Если о вас известно, что вы отшиваете всех, кто вам чем-то не понравился, наверно аудитория вас не полюбит.
Давайте экспертам какую-то выгоду. Это может быть как моральное удовлетворение от внимательного выслушивания, так и некая помощь в какой-то задаче, стоящей перед экспертом.
Сделайте так, что бы юные дарования не заполонили комментарии экспертными заявлениями на пару осмысленных слов. Да, здесь нужно стать модератором. Возможно поэтому, вам может пригодиться какая-то другая площадка.
И наконец, найдите место, где эксперты обсуждают что-то именно с экспертами. Если же вы пытаетесь что-то узнать на развлекательной площадке, то вам придётся очень и очень сильно постараться.
Возможно, автору стоит написать текст именно по проблеме поиска экспертной информации на развлекательных площадках, тогда и советов будет много, ну и какие-то эксперты могут за что-то начать уважать автора. Либо всё же найти готовую площадку с экспертами.
А по делу эксперту сказать совсем нечего или это ниже его достоинства?
А он всё по делу сказал.
По сути его слова - рекомендации к экономии энергии сообщества. Вам нужно не изобретать велосипед, что вы уже поняли судя по одному из ответов к посту. Далее - найти название той сферы исследовательской деятельности, участники которой заняты решением данных задач и ознакомиться с уже имеющимися результатами чужой мозговой деятельности, подкреплённой практикой. Достигнув среднестатистического уровня у вас могут появиться вопросы, которые, возможно, сообщество даже не ставило перед собой, но которые имеют отношение к сфере исследований. Вот это и есть движение вперёд.
Когда же я, впервые столкнувшись с какой-то проблемой и потратив на анализ проблемы целых 5 минут, начинаю отвлекать умных дяденек и тётенек детскими с их точки зрения вопросами, то это явное движение назад, т.к. высококлассные ресурсы тратятся нерационально.
Есть люди, которые тупые и они это понимают, поэтому никогда не лезут на трибуны и не пишут книг. Особенно если им вчера за тридцатник перевалило. Потому что понимают, что даже в ограниченном их языковой группой сообществе они наверняка не первые, кто столкнулся с какой-то проблемой, с которой может столкнуться тот, кто явно - не посвятивший всю жизнь копанию в одном научном направлении 80-летний специалист.
А есть те, кто в современном мире пытается продать себя подороже, понимая, что для этого нужно только чтобы тебя каждый утюг транслировал. Ходят по конференциями и рассказывают, как они решили бизнес-задачу внимательным прочтением инструкции к софтине или тем, что пришлось пропатчить библиотеку. Рассказывают сторисы, в-общем. Современные такие техно-барды. А ещё более юные им в рот смотрят и хотят быть "как они".
Как видно, CRUS даёт максимальные гарантии при сохранении доступности:
Не видно. Картинку видно, доказательство - нет.
Можно вместо дурацких картинок и копипасты википедии получить нормальное описание?
Прикольно. Правильно ли я понял, что это один из вариантов блокчейна, где не одноранговые узлы, а версия с узлами доверенными?
На чем реализовали? WebRTC?
Не, тут как раз нет никакого блокчейна, поэтому криптоспекулянтам тут делать нечего. Но доверенных узлов тут нет, ибо все узлы равны. Технически сейчас реализовано на веб-сокетах, добавление WebRTC и возможность каждому браузеру выступать сервером есть в планах.
Блокчейн же не только же в крипте может использоваться. Это просто один из механизмов децентрализованного хранения данных. Криптографическая защита от изменений, также используется криптография для добавления изменений в блокчейн.
Во всяком случае благодарю за ответ. Надо перечитать статью значит.
Для криптовалют необходим централизованный блокчейн, чтобы избегать двойной траты. Тут нет блокчейна - не подходит для криптовалют. А нет его потому, что он не совместим с коммуникацией в реальном времени и офлайном. А ещё он растёт бесконечно.
Автор, очень объёмная статья, её бы разбить на десяток поменьше, и выкладывать раз в неделю. И на ресурсе с тематикой СУБД. На хабре не поймут и не оценят.
В целом интересное чтение. Кажеться скорость работы такой системы будет не самая высокая, в силу её универсальности.
Надо бы пример развертывания и использования, если кроме теории есть реализация.
Надо бы сравнительных тестов с "конкурентами", с альтернативными решениями.
То есть материла у вас на серию статей, публикуйтесь !
По поволу аудитории, у меня рейтинг сильно ниже, но где ещё публиковаться ? При всем негативе, в коментах бывают дельные замечания, а на негатив не надо обращать внимание.
С одной стороны хороший совет о том, что нужно соблюдать объем для публикации.
А с другой стороны, ну, вот автор напишет первую из пяти глав. В лучшем случае посыпятся вопросы, ответы на которые, скорее всего, будут раскрыты в последующих частях.
Ещё высокая вероятность, что будут комментировать те, кто не читали предыдущие части.
Сложный вопрос, на самом деле "Как впихнуть невпихуемое".
Бенчмарков не хватает, особенно в сравнении с аналогами.
https://ru.wikipedia.org/wiki/Теорема_CAP - реализации распределённых вычислений
В оригинале: distributed data store, что согласитесь, немного другое. Теорема об ограничениях базы, если ее рассматривать как целое. Подсказка - делаете партиционирование, и ограничения исчезают.
А Вы сами практически с СУБД сетевой модели работали? Вот мне пришлось тесно пообщаться с IDMS. После неё переход даже на Adabas показался счастьем. Адаптивную модель на базе инвертированного индекса Вы, кстати пропустили.
Поддержка и постоянный рефакторинг в сетевой модели БД - огромная головная боль. А оптимизировать производительность чрезвычайно сложно и трудоемко. Реляционная модель тут выигрывает с отрывом. И зря Вы её обозвали табличной.
Попробуйте современные сетевые СУБД - почувствуете разницу.
Инвертированные индексы сейчас используют в любой СУБД.
Ну и попробуйте пооптимизировать SQL запросы, когда планировщик является черным ящиком, а возможностей по реорганизации хранения у него ноль
Пробовал. Да те же самые проблемы с архитектурой, что и были. Укажите конкретную, в которой перестроение ссылок и цепочек происходит с такой же легкостью и скоростью, как добавление и удаление индексов и внешних ключей в SQL.
Не путайте инвертированные индексы для таблиц с адаптивной СУБД на их базе.
Оптимизациями SQL запросов для CH, PostgreSQL и MS SQL я занимаюсь чуть ли не ежедневно. Так что непонятно, что я ещё должен там попробовать?
OrinetDB, например. Даже диалект SQL поддерживает.
Я без понятия, что такое "адаптивная субд" и почему остальные сетевые субд вдруг "неадаптивные".
Вот именно, что тратите кучу времени на борьбу с планировщиком запросов, вместо того, чтобы явно формировать поисковые структуры.
OrinetDB, например
Там те же самые проблемы, так как связи физические.
Попробуйте создать на ней более-менее крупную структуру версионных справочников, для примера, с daterange. И посмотрите, во что вытекает вставка и модификация операций хотя бы с десятком-другим аналитик. Попробуйте потом модифицировать записи справочников со сменой периода действия записи.
А потом сравните этот сценарий с таким же на PostgreSQL.
Вот тогда придет просветление, что в реальной жизни, когда реляционные связи далеко не только равенство двух ID, сетевая модель неэффективна.
SQL поддерживает
Это не SQL
Я без понятия, что такое "адаптивная субд"
Если Вам лениво почитать про Adabas, то почему я из-за этого должен Вам рассказывать о ней здесь?
Вот именно, что тратите кучу времени
Ну я бы не сказал, что несколько минут, а порой и секунд - это куча времени.
на борьбу с планировщиком запросов, вместо того, чтобы явно формировать поисковые структуры.
Принципиальная разница в том, что потратив совсем немного времени можно добиться достаточно оптимальной выборки без модификации БД. Тогда как в случае сетевой модели оптимизация заключается в модификации БД и создании новых связей, что уже на терабайтных объемах - действительно КУЧА времени.
Не физические, но переход по связям имеет константную сложность, в отличие от реляционной модели. И представьте себе, вторичные индексы тоже поддерживаются. Но в отличие от реляционной модели, где они лишь глобальные, в сетевой они могут быть ещё и локальными, что существенно быстрее. Про возможность постепенной миграции схемы без блокировки всей базы я вообще молчу. Иронично, что как раз у PostgreSQL куча проблем из-за физических смещений в индексах и кривой репликации (через WAL).
А вы что доказать-то пытаетесь? Что я дурак, а вы эксперт? Ну держите 👑, мне не жалко. Может обсудим что-то более полезное?
Еще раз, цена константной сложности - константные связи. И если в справочнике контрагентов запись, с периодом действия два года разделяется на записи с периодом действия по году, то для реляционной модели - это легко и просто, тогда как для сетевой - обновление миллионов связей.
А доказать я пытаюсь, что золотого молотка не бывает. И судьба сетевой модели - ограниченная область применения. Впрочем, тоже самое относится и к реляционной модели. И из того, что их области применения пересекаются, вовсе не следует, что они совпадают, как может показаться после прочтения Вашей статьи. Понятно, что как у реляционной модели PostgreSQL есть костыль в виде Apache AGE, так и у сетевой модели может быть соответствующий костыль. Но костыль остается костылем, нравится Вам это или нет.
P.S. Убедительная просьба воздержаться от перехода на личности. Подобные аргументы в технической дискуссии - явный признак демагогии.
Статья интересная, спасибо за труд, прочитать на досуге можно.
Кстати, реализовать BLS можно, но не для ts, я в нём не силён, на расте — можно.
А на расте вроде уже есть: https://docs.rs/ark-bn254/
Для построения сети можно использовать libp2p, или написать ее заново, в Вашем случае.
Я так понял, предполагается наследование прав ограничить одним уровнем? То есть можно создать арию в home, но внутри этой арии создать другую уже нельзя? Кажется, это сильно ограничивает возможности системы.
Хорошо что есть Deepseek R1
Развернутая рецензия на статью "CRUS: принципиально новая архитектура работы с данными"
1. Структура и стиль изложения
Сильные стороны:
Статья построена как исследовательский манифест, что привлекает внимание к амбициозным идеям.
Использование метафор (например, "Святой Грааль работы с данными") делает материал доступным для неспециалистов.
Слабые стороны:
Несбалансированность теории и практики: Автор детально описывает концепции (CVRDT, шардирование), но избегает конкретных алгоритмов или схем реализации. Например:
Нет псевдокода для синхронизации лендов.
Не объяснено, как именно достигается "атомарность" в RAW-подходе.
Субъективные оценки: Утверждения вроде "деревья — частный случай графов, поэтому сетевая модель лучше" игнорируют контекст применения. Для OLTP-задач реляционные модели часто эффективнее благодаря ACID-гарантиям.
2. Технические аспекты
2.1. Преодоление CAP-теоремы
Заявлено: CRUS выбирает AP (доступность и устойчивость к разделению), жертвуя согласованностью (C).
Критика:
Автор не объясняет, как система обеспечивает конечную согласованность (eventual consistency). Например:
Нет механизма разрешения конфликтов при одновременном изменении одного юнита разными узлами.
Не описано, как обрабатываются "потерянные обновления" (Lost Update), которые неизбежны в AP-системах.
Упоминание PACELC-теоремы поверхностно. Если CRUS оптимизирована для задержек (EL), как это сочетается с гарантиями актуальности (PA)?
2.2. Безопасность
Заявлено:
Zero Trust + E2E-шифрование + Ed25519 для подписей. Критика:
Уязвимости в AES-CBC: Режим CBC без аутентификации (HMAC) подвержен атакам на паддинг (padding oracle). Автор игнорирует это, утверждая, что "аутентификация достигается через подписи", но подпись не защищает от модификации ciphertext.
Недостаток в авторизации: Система прав на уровне лендов слишком грубая. Например, как ограничить доступ к части данных внутри ленда?
2.3. Модель данных
Заявлено:
Графовая модель с шардированием на "ленды". Критика:
Проблема связей между лендами: Если узел в ленде A ссылается на узел в ленде B, как гарантируется атомарность их синхронизации?
Слабая типизация: Идея "реинтерпретации DOM как JSON" звучит рискованно. Например, если пользователь А редактирует XML-документ, а пользователь B видит его как JSON, это может привести к семантическим конфликтам.
2.4. Криптография
Заявлено:
Использование BN-254 для компактных подписей (32 байта вместо 64). Критика:
Криптостойкость BN-254: Упомянутые 100 бит недостаточны для долгосрочной безопасности. NIST рекомендует минимум 128 бит для симметричных алгоритмов.
Отсутствие реализаций: Автор признаёт, что "с реализациями всё плохо", но не предлагает пути решения (например, использование альтернатив вродя BLS12-381).
3. Практическая реализация
Заявлено:
CRUS уже можно "пощупать" на сайте crus.hyoo.ru. Критика:
Нет доказательств работоспособности:
Нет тестов производительности (например, latency при синхронизации 10 тыс. юнитов).
Нет сравнения с аналогами (IPFS, Cassandra, GunDB).
Сомнительные оптимизации:
Фиксированный размер юнита (128 байт) может привести к избыточному расходу памяти. Например, хранение булева значения (1 бит) занимает 128 байт — это 1024-кратное увеличение.
Генерация идентификаторов через Proof of Work (PoW) с префиксом 0xFF повышает энергозатраты без явных преимуществ.
4. Методологические изъяны
Игнорирование состояния искусства:
Нет ссылок на работы по CRDT (например, исследования Марка Шапиро) или децентрализованным базам (например, DynamoDB, Riak).
Упрощение Jepsen-тестов: автор "рефакторит" классификацию, но не приводит примеров тестирования CRUS через Jepsen-фреймворк.
Рекламные элементы:
Критика Хабра ("отношение к авторам скверное") выглядит как попытка перевести внимание с недостатков статьи.
Упоминание "монетизации рублём" в планах ставит под сомнение академическую честность проекта.
5. Рекомендации для автора
Углубить техническую аргументацию:
Привести схемы синхронизации лендов и разрешения конфликтов.
Объяснить, как достигается атомарность в RAW-подходе без WAL.
Добавить сравнительный анализ:
Сравнить CRUS с IPFS (децентрализация), Cassandra (AP-система), SQLite (ACID).
Исправить уязвимости в безопасности:
Перейти с AES-CBC на AEAD-режимы (например, AES-GCM).
Реализовать механизм fine-grained access control.
Провести практическое тестирование:
Опубликовать метрики производительности и результаты стресс-тестов.
Интегрировать Jepsen для проверки гарантий согласованности.
Итог
CRUS — смелая попытка переосмыслить архитектуру распределённых систем, но её текущее состояние ближе к теоретическому эссе, чем к готовому решению. Автору необходимо:
Избегать декларативных утверждений ("это возможно") в пользу доказательных ("мы достигли этого через алгоритм X").
Устранить методологические пробелы (CAP, безопасность, типизация).
Предоставить независимой аудитории возможность проверить заявленные преимущества.
Пока статья вызывает больше вопросов, чем ответов, но при доработке CRUS может стать интересным исследовательским направлением.
CRUS: принципиально новая архитектура работы с данными