The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Fedora планирует перевести RPM с BerkeleyDB на SQLite, opennews (?), 17-Мрт-20, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


53. "Fedora планирует перевести RPM с BerkeleyDB на SQLite"  –2 +/
Сообщение от Аноним (53), 17-Мрт-20, 16:47 
А велосипедить объектное достаточно простое кей-валью с отн. узким назгачением в реляционке общего назначения это не велописедить
Альтернативы у бдб есть
Ответить | Правка | Наверх | Cообщить модератору

66. "Fedora планирует перевести RPM с BerkeleyDB на SQLite"  +5 +/
Сообщение от нона (?), 17-Мрт-20, 18:22 
> А велосипедить объектное достаточно простое кей-валью с отн. узким назгачением в реляционке общего назначения это не велописедить

То, что изначальная задача натянулась на KV не значит, что она не реализуется проще на реляционке.

> Альтернативы у бдб есть

Я знаю только одну, с хорошей durability (а это очень важно для zero-maintanence тула), которая натягивается со скрипом из-за нюансов mmap: lmdb. Я много работал с lmdb, bdb, leveldb и выбор sqlite для rpm более чем разумен, из-за количества необходимой меты и того количества головняков, которое берет на себя sqlite по надежной записи данных на диск.  

Ты, кстати, альтернативы не озвучил.

Ответить | Правка | Наверх | Cообщить модератору

87. "Fedora планирует перевести RPM с BerkeleyDB на SQLite"  +/
Сообщение от Аноним (42), 18-Мрт-20, 07:29 
Какая идея-то?? Реляционка нужна для одного и только одного - перекрестных внезапно реляций. А они в свою очередь для аналитики. Шапка собирается у своих хомячков-клиентов в режиме лайв на продакшн серверах анализировать её же (шапковые) пакеты? обучать нейро-сеть? Или что?
То что не нужно анализировать нужно хранить в объектном хранилище. Это внезапно проще программировать и просто проще а значит надёжнее. Неплохая рекомендация для основы ОС, нес па?
На сайте федоры только жалобы на не поддерживаемость старой версии и невозможность перехода на новую из-за смены лицухи Ораклом. Ну так себе повод переходить на принципиально другую философию...
Так что нужно озвучить сначала идею, а потом уже всё остальное. В т.ч. и альтернативы типа LDBM
Ответить | Правка | Наверх | Cообщить модератору

88. "Fedora планирует перевести RPM с BerkeleyDB на SQLite"  +/
Сообщение от нона (?), 18-Мрт-20, 08:38 
> Какая идея-то??

Это риторический вопрос? Разверните, пожалуйста, если нет, не понятно что вы спрашиваете.

> Реляционка нужна для одного и только одного - перекрестных внезапно реляций. А они в свою очередь для аналитики. Шапка собирается у своих хомячков-клиентов в режиме лайв на продакшн серверах анализировать её же (шапковые) пакеты? обучать нейро-сеть? Или что?

У дона истерика. Вам надо успокоиться. Это слишком хитрый план.

1) У RH и так есть live-стата у кого какой пакет по-клиентно. Пакеты качаются с серверов RH с авторизацией.
2) У федоры есть обезличенная стата.
3) Никакой проблемы вытащить туже информацию с bdb/lmdb/KV нет. Иначе каким образом rpm работает?

Поэтому нет, sqlite нужен не для аналитики и нейронок. А чтобы убрать кучу кода, которая велосипедит реляционку поверх BDB.

> То что не нужно анализировать нужно хранить в объектном хранилище.

Дон стремительно превращается в дремучий валенок. Каким образом объектное хранилище помешает взять аналитику?

Кстати, можно примеры надежных встраиваемых объектных хранилищ? Я за 20 лет ни одного не видел, все какие-то поделки с красивыми рекламными плакатами.

> В т.ч. и альтернативы типа LDBM

Хм. Дон же не думает что KV это объектные хранилища? Иначе это шизофрения. KV-store это отображение одного набора байт в другое. Как правило c range-индексом по K в нагрузку, из-за особенностей реализации. Это очень low-level абстракция, которая начинает быстро обрастать реляционными обвязками на мало-мальски сложных моделях данных. Модель хранения пакетов уж точно переросла это порог.

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру