The OpenNET Project / Index page

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



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

Оглавление

Berkeley DB переведён на лицензию AGPLv3, что привело к проб..., opennews (ok), 07-Июл-13, (0) [смотреть все]

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


126. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 10:49 
На SQLite перейдут ...
Ответить | Правка | Наверх | Cообщить модератору

141. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от 333 (?), 08-Июл-13, 15:18 
LDAP???
Ответить | Правка | Наверх | Cообщить модератору

158. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 15:59 
> LDAP???

Лдап? С скулайтом? Бобби Тэйблс быстро вам объяснит что вы не правы :)

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

210. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от 333 (?), 08-Июл-13, 21:02 
http://pro-ldap.ru/tr/admin24/intro.html#LDAP vs RDBMS
ldap vs sql - вещи плохо совместимые.
вместо bdb можно разве что какую-нибдь NoSQL с бинарными деревьями.
Ответить | Правка | Наверх | Cообщить модератору

211. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  –1 +/
Сообщение от AlexAT (ok), 08-Июл-13, 21:11 
NoSQL+BTREE? Тогда уж SQL/BTree - классику, ибо снявши голову...
Ответить | Правка | Наверх | Cообщить модератору

296. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 09-Июл-13, 14:02 
> NoSQL+BTREE? Тогда уж SQL/BTree - классику, ибо снявши голову...

А зачем работать с b-деревом через такую жо... ой, то-есть, бутылочное горлышко SQL?

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

332. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  –1 +/
Сообщение от AlexAT (ok), 09-Июл-13, 23:59 
> А зачем работать с b-деревом через такую жо... ой, то-есть, бутылочное горлышко
> SQL?

Да я не спорю, можно и с сотней гектаров земли лопатой поработать... но проще взять трактор.
А там, где сотни гектаров нет - и разницы не будет, в общем. Есть трактор - хорошо. Нет - тоже хорошо.

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

347. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 10-Июл-13, 12:15 
> Да я не спорю, можно и с сотней гектаров земли лопатой поработать...

Сам по себе kay-value может прекрасно работать с любым объемом данных. Хоть с терабайтом. Доказано файловыми системами :).

В случае b-дерева скорость O(log(n)), а в хэш-таблицах вообще O(1). Во втором варианте размер вообще не роялит - вытаскивание записи не зависит от размера базы.

> но проще взять трактор.

Если посмотреть на нашего любимого враженьку (у конкурентов надо учиться хорошему) - майкрософтушка при наличии у них в портфолио сиквель сервера который они впаривают при каждом удобном случае, тем не менее допер поюзать для активной директории и эксченжа совершенно другой тип стоража - ESE storage engine. Некую хрень с куда более простым доступом но зато куда более быструю. И таки нормальное инженерное решение им воздалось - у всех остальных и по сей день большие проблемы с эквивалентной заменой что AD что Exchange.

> А там, где сотни гектаров нет - и разницы не будет, в
> общем. Есть трактор - хорошо. Нет - тоже хорошо.

Буллшит. Вон майкрософт для кучи гектаров в энтерпрайзе как раз подогнал специализированное двигло где никаким SQL и не пахло, как минмум изначально.

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

353. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от arisu (ok), 10-Июл-13, 16:13 
> В случае b-дерева скорость O(log(n)), а в хэш-таблицах вообще O(1). Во втором
> варианте размер вообще не роялит — вытаскивание записи не зависит от
> размера базы.

зависит, естественно. как минимум потому, что O(1) — это только в идеале. и база не в астрале хранится.

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

359. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 11-Июл-13, 18:39 
> зависит, естественно. как минимум потому, что O(1) — это только в идеале.
> и база не в астрале хранится.

Тем не менее, если библа обещает 2 дисковые операции - они так и будут 2 дисковыми операциями. Иррелевантно к объему файла. Насколько там ФС окочурится и прочая - вообще оффтопик, ибо проблемы ФС - ну вообще никак не вина БД :)

Тем не менее, сами по себе ФС вон масштабируются на терабайты - и ничего, работает. Нормально вполне вроде.

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

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

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




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

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