home.social

#nosql — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #nosql, aggregated by home.social.

  1. Одна таблица результатов на 14 движков: как мы перестали дорисовывать то, чего движок не умеет

    Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

    habr.com/ru/articles/1079790/

    #базы_данных #SQL #NoSQL #IDE #selfhosted #open_source #PostgreSQL #Cassandra #Trino #LibreDB

  2. Одна таблица результатов на 14 движков: как мы перестали дорисовывать то, чего движок не умеет

    Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

    habr.com/ru/articles/1079790/

    #базы_данных #SQL #NoSQL #IDE #selfhosted #open_source #PostgreSQL #Cassandra #Trino #LibreDB

  3. Одна таблица результатов на 14 движков: как мы перестали дорисовывать то, чего движок не умеет

    Сразу оговорюсь: я из команды LibreDB Studio, и статья — про наши собственные грабли. LibreDB Studio — это self-hosted IDE для СУБД, работающая в браузере: один инстанс разворачивается рядом с базами, а не устанавливается на ноутбук каждого разработчика. Команда открывает URL — и почти сразу упирается в вопрос, который сожрал у нас не один спринт: как показать результат из четырнадцати принципиально разных движков в одной таблице и при этом не начать выдавать пользователю выдумки за реальные данные.

    habr.com/ru/articles/1079790/

    #базы_данных #SQL #NoSQL #IDE #selfhosted #open_source #PostgreSQL #Cassandra #Trino #LibreDB

  4. INDB: когда все лгут, помнит, что вы видели

    В любой записи в базу зашито допущение: у факта одно значение. Два несовпадающих наблюдения об одном объекте — конфликт, который положено разрешить до коммита, и разрешается он UPDATE . Пока данные генерирует ваш же код, допущение верное. Ломается оно на наблюдениях. Сенсоры расходятся в показаниях, и оба показания настоящие. Агент пишет о состоянии файла, который человек уже поправил руками. Два источника сообщают разное, и разрешить противоречие в момент записи нечем — контекст, в котором одно из них весит больше, появляется только в момент вопроса. INDB стоит на этом: смысл производится при чтении, а не фиксируется при записи . Вместо CRUD три фазы — вдох ( Inhale , принять сырое наблюдение), выдох ( Exhale , сжать повторы и отфильтровать шум репутацией), аксиома ( Axiom , подписать то, что выжило).

    habr.com/ru/articles/1073372/

    #database #database_development #nosql #llm #agents

  5. Объектное хранилище SQL — прямо в вашей PostgreSQL/MS SQL/SQLite.EF и Dapper рядом. redb против Mongo и Raven

    Чтобы хранить объекты, графы и деревья с типами, индексами и полноценными запросами, вам не нужна ещё одна база данных. Нужна та, что у вас уже есть. redb превращает PostgreSQL, MS SQL или SQLite в типизированное объектное хранилище, не отнимая ни SQL, ни EF Core, ни Dapper. Это принципиально другой разговор, чем «MongoDB против RavenDB»: там вы выбираете отдельный движок и живёте с ним отдельно; здесь объекты ложатся в базу, которая у вас уже крутится в проде. Ниже чем это выигрывает у документных баз, с кодом, и где у redb честные границы. Чтобы не спорить с чучелами: MongoDB зрелая серверная документная база с горизонтальным масштабированием и огромной экосистемой, и мультидокументные ACID-транзакции у неё есть с версии 4.0 (2018). RavenDB .NET-native документная база, полностью ACID, с типизированным LINQ и автоиндексами. Обе хорошие продукты. redb просто играет на другом поле и на этом поле у него сильные карты. И учить, по сути, нечего: это тот же LINQ, который вы уже пишете. Код против redb и против Raven почти совпадает (ниже увидите), а порог входа ниже, чем у EF Core, без DbContext , конфигурации и миграций.

    habr.com/ru/articles/1072170/

    #dotnet #postgresql #mongodb #ravendb #nosql #ef_core #dapper

  6. Масштабируй! Почему Cassandra 5 стала спасением, а FoundationDB прилегла в чулан

    Привет, Хабр! Меня зовут Роман Ананьев из команды DBA в Авито . В этой статье я расскажу о поиске альтернативы для многошардовых инсталляций MongoDB. Основная цель исследования — найти базу данных с поддержкой автошардирования, которая упростит эксплуатацию и лучше утилизирует ресурсы. Когда проект вырастает из уютных нескольких шардов MongoDB и превращается в огромную систему на сотни узлов, стандартные подходы к масштабированию начинают пожирать железо и время инженеров. Здесь продуктовый инженер упирается в ресурсы, и у него начинается головная боль, как перелить данные из одних шардов в другие. Это текст не про то, что MongoDB плохая, она — прекрасный стандарт рынка, в топ-5 движков БД. Я расскажу про то, что происходит, когда у стандартной технологии заканчивается запас прочности на нужном масштабе, и про то, как мы в Авито перебрали множество NoSQL и NewSQL кандидатов, чтобы найти одного подходящего. В статье я разберу результаты технического исследования, проведённого командой DBA. Мы сравнили производительность, утилизацию ресурсов и архитектурные грабли Cassandra 5, FoundationDB и других БД. Также объясню, почему погоня за низкой latency в случае с FDB обернулась трёхкратным перерасходом дискового пространства.

    habr.com/ru/companies/avito/ar

    #базы_данных #nosql #foundationdb #apache_cassandra #хранение_данных #сравнение_производительности #сравнение_баз_данных

  7. Катапультирование из DSE и миграция на Scylla

    Если ты к чему-то привык, и все кажется удобным и комфортным, при понимании, что это может закончиться в любой момент, надо выбирать, что делать дальше. Так и с решениями, которые мы уже как-то внедрили — несмотря на то, что они прекрасно показывают свою эффективность, наступают моменты, когда их приходится пересматривать, и делать это весьма оперативно. В данном случае речь о системе с СУБД DSE — удобной, отлично адаптированной к использованию под наши задачи, распределенной СУБД NoSQL-типа на базе Apache Cassandra с пудовыми рисками прекращения лицензирования со стороны Datastax. При этом пересаживаться на другой «стул» требуется, разумеется, бесшовно, без потерь в вопросах производительности, безопасности и эксплуатационного качества в продукте. Вопрос это для нас особо важный, так как сама система, для которой рассматривалась замена СУБД высококритичная, и требования к решению были неизменными: возможность вертикального масштабирования «на лету» для поддержки значительного увеличения объема хранимых данных, высокая производительность записи и поддержка отказоустойчивости, включая распределение СУБД в нескольких ЦОД. У нас уже был накоплен весомый багаж информации в текущей базе, поэтому сама технология СУБД требовалась сродная по типу для исключения проблемы со сложностью миграции данных. В статье начальник группы внедрения и тестирования продуктов и услуг Nexign Анна Алешина рассказывает, почему мы выбрали Scylla и решили прокачать ее до собственной «фирменной» СУБД Nexylla. Материал будет полезен всем, кто тоже задумывается о миграции на более надежные с точки зрения лицензирования СУБД.

    habr.com/ru/companies/nexign/a

    #scylla #базы_данных #scylladb #ssd #cassandra #nosql #администрирование_баз_данных