Тупейший кстати вопрос, ни разу не видел их в небиблиотечном коде, да и вешать такие вещи в память в интерпретируемом языке это совсем надо быть сениор пайтон арчитектом))
Ну кстати на этот вопрос зачем "нужно искусственно фабриковать человека, когда любая баба может его родить когда угодно?" у меня давно сформировался ответ. Чтобы получить нормального работника из человека, его надо родить и потом обучать много лет с непредскауемым результатом. А программы они plug-able так скажем, легко, быстро, и бесплатно тиражируются, предсказуемое качество и т.д.
Кассу и платежи надо дробить по периодам, есть понятие - касовая смена, вообще это общий подход при работе с супер-нодами.
Про индекс, если хранить указатель to_id прямо в индексе, вообще без таблиц, то да верно. Так как раз работает Blazegraph, и Neptune получается тоже, я сейчас вспомнил ошибки были про btree, видимо используют из RDS.
Я думаю random-read "в среднем" меньше, потому что отличия в скорости реально видны. Причина может быть в более простом шардировании с концепцией нода, а не таблицы, и в кешированиии по той же причине. Ну и плюс типичные SQL движки не могут так джоинить указатели, да, это возможно с b+tree, но реалиовано в тех базах, которые считаются графовыми (Blazegraph, Neptune, JanusGraph например, ElasticSearch для шардированого b+tree и Cassandra для остальных данных). А вот Neo4j, к примеру, не на b+tree, а на double linked list https://neo4j.com/developer-blog/relationship-chain-locks-dont-block-the-rock/ TigerGraph тоже заявляют что у них не hashmap там.
Да, adjacency list может быть типа b-tree только он маленький локальный, а не вся таблица целиком как в табличной базе. Плюс этот adjacency list читается разом с диска в память, а в табличной сначала нужно прочитать индекс кусками (весь в RAM не поместится), пока не найдешь всех нужных, потом куча random read'ов чтобы достать данные, на следующем шаге все по новой. Представьте таблицу для друзей from_id,to_id. Сначала сканируем всю from_id (первый огромный индекс), потом всю to_id таким же образом (потому что может быть связь в другом направлении), потом достаем данные из ячеек - to_id для from, from_id для to. Это первый шаг. Потом снова сканируем два огромных индекса, только уже для каждого друга первого порядка. Вообщем обычно даже на 100к юзеров табличная база ложится уже на третьем хопе. Neptune да, больше похож на фейк, типа у нас есть графовая база, там я помню в начале он даже ошибки RDS выбрасывал, потом спрятали.
Обучать можно на ГДЗ по математике, я думаю)) там и тексты задач, и системы уравнений из них, и разбор решений с комментариями. Я просто представитель конкурирующей технологии, наблюдял в соцсетях как это было. Сначала они релизнули, и все начали постить эти задачки и типа "смотрите, у нее 2+2=5, а вы собрались ей свой бизнес доверить", пошел негативный фон. Потом был даунтайм на сутки, где то 10 января, и после него она начала решать. Да. все верно: 0 Определить что пользователь опять троллит мат.задачами 1 Составить систему уравнений по текстовому описанию задачи (сложно сказать как, gpt-чатбот не сможет, первое что приходит на ум это стандартный NLP+графы) 2 Решить систему в матлабе 3 По решению составить текстовое описание (это должно быть попроще)
А это же недавно добавили, в маркетинговых целях, так скажем. Сначала она ничего решать не могла, давала рандомные ответы из похожих текстов, все смеялись типа лажа. Я так думаю там не нейросеть (gpt) для математики, а просто решалка как в матлабе, просто обернутая чат-ботами на входе и выходе.
А может кто-то объяснить, что это за страшилка, которую SQL-ребята каждый раз про Mongo рассказывают, типа при она не сразу данные на диск пишет? Вроде бы у того же Postgres тоже есть WAL, который он сбрасывает на диск периодически, но не сразу.
Ну наверное не будет второго index scan как минимум. Композитный хеш-индекс (если он имеется ввиду) это тоже как бы граф, но с поддержкой только одного запроса (c1,c2,c3), а нормальный граф это "индекс" во все стороны. При обновлении перепишутся adjacency list'ы локально
Лол, она обучена на вероятностях того что одно слово идёт за другим, а люди верят что это абстрактное мышление)) как раз Тьюринг в трактате приводил пример с перекладыванием китайских карточек. Это все треш, языковые модели, если уж AI - то symbolic AI с треугольником concept-symbol-obhect
Про более сложную структуру (локальный индекс на вершине), да, я думал, там две проблемы. 1) там сейчас уже хеш-таблица на каждой вершине, из-за типов edges и IN/OUT, в neo4j вершина уже 15 байт из-за этого, ну вот похожие решения https://www.datastax.com/blog/solution-supernode-problem
2) второй момент для меня более важен, этот индекс должен зависеть от каких-то свойств вершин-соседей, а это coupling нам этого не надо
С большим интересом взгяну на такой пример с необходимостью такого stateful замыкания для frontend, да даже пускай в node
где бы посмотреть этот Travelling Salesman (Коммивояжёр, 2012)?
Тупейший кстати вопрос, ни разу не видел их в небиблиотечном коде, да и вешать такие вещи в память в интерпретируемом языке это совсем надо быть сениор пайтон арчитектом))
это из-за JIT может не видно
Ну кстати на этот вопрос зачем "нужно искусственно фабриковать человека, когда любая баба может его родить когда угодно?" у меня давно сформировался ответ. Чтобы получить нормального работника из человека, его надо родить и потом обучать много лет с непредскауемым результатом. А программы они plug-able так скажем, легко, быстро, и бесплатно тиражируются, предсказуемое качество и т.д.
А эмоции это loss-function ))
Вообще-то в физике как раз запрещают считать "в уме" / "в столбик", только на калькуляторе
Кассу и платежи надо дробить по периодам, есть понятие - касовая смена, вообще это общий подход при работе с супер-нодами.
Про индекс, если хранить указатель to_id прямо в индексе, вообще без таблиц, то да верно. Так как раз работает Blazegraph, и Neptune получается тоже, я сейчас вспомнил ошибки были про btree, видимо используют из RDS.
Я думаю random-read "в среднем" меньше, потому что отличия в скорости реально видны. Причина может быть в более простом шардировании с концепцией нода, а не таблицы, и в кешированиии по той же причине. Ну и плюс типичные SQL движки не могут так джоинить указатели, да, это возможно с b+tree, но реалиовано в тех базах, которые считаются графовыми (Blazegraph, Neptune, JanusGraph например, ElasticSearch для шардированого b+tree и Cassandra для остальных данных). А вот Neo4j, к примеру, не на b+tree, а на double linked list https://neo4j.com/developer-blog/relationship-chain-locks-dont-block-the-rock/ TigerGraph тоже заявляют что у них не hashmap там.
Да, adjacency list может быть типа b-tree только он маленький локальный, а не вся таблица целиком как в табличной базе. Плюс этот adjacency list читается разом с диска в память, а в табличной сначала нужно прочитать индекс кусками (весь в RAM не поместится), пока не найдешь всех нужных, потом куча random read'ов чтобы достать данные, на следующем шаге все по новой. Представьте таблицу для друзей from_id,to_id. Сначала сканируем всю from_id (первый огромный индекс), потом всю to_id таким же образом (потому что может быть связь в другом направлении), потом достаем данные из ячеек - to_id для from, from_id для to. Это первый шаг. Потом снова сканируем два огромных индекса, только уже для каждого друга первого порядка. Вообщем обычно даже на 100к юзеров табличная база ложится уже на третьем хопе.
Neptune да, больше похож на фейк, типа у нас есть графовая база, там я помню в начале он даже ошибки RDS выбрасывал, потом спрятали.
Да, никак не умаляет, просто это не GPT уже, а срочная "заплатка" из другой технологии.
Обучать можно на ГДЗ по математике, я думаю)) там и тексты задач, и системы уравнений из них, и разбор решений с комментариями.
Я просто представитель конкурирующей технологии, наблюдял в соцсетях как это было. Сначала они релизнули, и все начали постить эти задачки и типа "смотрите, у нее 2+2=5, а вы собрались ей свой бизнес доверить", пошел негативный фон. Потом был даунтайм на сутки, где то 10 января, и после него она начала решать.
Да. все верно:
0 Определить что пользователь опять троллит мат.задачами
1 Составить систему уравнений по текстовому описанию задачи (сложно сказать как, gpt-чатбот не сможет, первое что приходит на ум это стандартный NLP+графы)
2 Решить систему в матлабе
3 По решению составить текстовое описание (это должно быть попроще)
А это же недавно добавили, в маркетинговых целях, так скажем. Сначала она ничего решать не могла, давала рандомные ответы из похожих текстов, все смеялись типа лажа. Я так думаю там не нейросеть (gpt) для математики, а просто решалка как в матлабе, просто обернутая чат-ботами на входе и выходе.
А может кто-то объяснить, что это за страшилка, которую SQL-ребята каждый раз про Mongo рассказывают, типа при она не сразу данные на диск пишет? Вроде бы у того же Postgres тоже есть WAL, который он сбрасывает на диск периодически, но не сразу.
Про WITH это кстати правда, так и есть
Ну наверное не будет второго index scan как минимум. Композитный хеш-индекс (если он имеется ввиду) это тоже как бы граф, но с поддержкой только одного запроса (c1,c2,c3), а нормальный граф это "индекс" во все стороны. При обновлении перепишутся adjacency list'ы локально
Лол, она обучена на вероятностях того что одно слово идёт за другим, а люди верят что это абстрактное мышление)) как раз Тьюринг в трактате приводил пример с перекладыванием китайских карточек. Это все треш, языковые модели, если уж AI - то symbolic AI с треугольником concept-symbol-obhect
это override
это ссылка из википедии https://en.m.wikipedia.org/wiki/Graph_Query_Language секция " The first implementation"
Есть еще вот https://arxiv.org/abs/2112.06217
А вот собственно и пруфы https://github.com/OlofMorra/GQL-parser/tree/main/src/test/resources/queries/gql/presentation
Да, точно, там же фильтровать надо будет еще false'ы, спасибо.
Про более сложную структуру (локальный индекс на вершине), да, я думал, там две проблемы. 1) там сейчас уже хеш-таблица на каждой вершине, из-за типов edges и IN/OUT, в neo4j вершина уже 15 байт из-за этого, ну вот похожие решения https://www.datastax.com/blog/solution-supernode-problem
2) второй момент для меня более важен, этот индекс должен зависеть от каких-то свойств вершин-соседей, а это coupling нам этого не надо