The OpenNET Project / Index page

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



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

Оглавление

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

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


34. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  –1 +/
Сообщение от vitalifemail (?), 07-Июл-13, 17:33 
Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB :DD

Кал ведь ещё тот...

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

108. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 01:56 
> переход на agpl3 вами, последовательными "сторонниками свободного по", должен быть одобрен

Вот это и был бы условный рефлекс на недостаточную информацию.

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

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

139. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  –2 +/
Сообщение от linux must __RIP__ (?), 08-Июл-13, 14:09 
> Дааааа, а теперь покажите мне дурака, который купит платную лицензию на BDB
> :DD
> Кал ведь ещё тот...

очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили) может выполняться в kernel space.. + в качестве примеров идет чуть ли не кусок журналируемой файлухи.. - очень не плохой вариант.. Вы видимо готовить его не умеете?

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

147. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 15:33 
> очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили)
> может выполняться в kernel space.. + в качестве примеров идет чуть
> ли не кусок журналируемой файлухи.. - очень не плохой вариант..

Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут, так даже интереснее.

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

160. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 16:01 
> Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут,
> так даже интереснее.

Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные апи. И документировано неплохо.

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

162. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 16:09 
Для типового проекта на ее базе 99% функционала просто не нужно.
Ответить | Правка | Наверх | Cообщить модератору

193. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 17:35 
> Для типового проекта на ее базе 99% функционала просто не нужно.

В любом случае, базы данных, даже простые - относительно навороченный и сложный кусок знаний, который типичному прикладнику вгружать в свою голову совершенно не с руки.

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

197. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 08-Июл-13, 17:55 
> В любом случае, базы данных, даже простые - относительно навороченный и сложный
> кусок знаний, который типичному прикладнику вгружать в свою голову совершенно не
> с руки.

Типичный прикладник BDB за пять километров стороной обходит. И правильно делает, кстати.

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

292. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  +/
Сообщение от Аноним (-), 09-Июл-13, 13:57 
> Типичный прикладник BDB за пять километров стороной обходит. И правильно делает, кстати.

Вот только я с этой базой именно на примере нужной мне прикладухи и познакомился. Там вылезли грабли, и по этому поводу меня ждала целая экскурсия в мир BDB и даже ее внутренностей немного. В целом увиденное понравилось. Хорошо написана дока, понятно как юзать. Фич прилично. Все логично сделано.

Да, а самое приятное - разработчики из sleepycat помогли умахать грабли (оказавшиеся платформо-специфичными) - буквально не более 2 дней на переписку и пришло понимание места где рукоятка грабель внезапно встречается со лбом. При том ни цента за такой годный саппорт не запросили + запатчили грабли в апстриме и выкатили новую версию довольно оперативно.

Не знаю, насколько они испортились после покупки ораклем, но до этого с ними и их базой было вполне приятно иметь дело.

Из того что НЕ понравилось: оно довольно большое и фич там на порядок больше чем обычно надо от key-value, добавляет довольно много кода. Потом они даже SQL сделали. И скорость работы не чемпионская в своем классе.

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

208. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 08-Июл-13, 19:45 
> Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная
> и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные
> апи. И документировано неплохо.

я уже как-то даже подустал: LMDB: http://symas.com/mdb/

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

214. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  –1 +/
Сообщение от Аноним (-), 08-Июл-13, 21:30 
> я уже как-то даже подустал

Милорд, в этом обсуждении нужно больше ссылок на LMDB.

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

222. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от arisu (ok), 08-Июл-13, 22:01 
> Милорд, в этом обсуждении нужно больше ссылок на LMDB.

нужно. потому что куча народу о ней не в курсе. и не все подписаны на обновления, так что некоторые анонимусы, которым оно будет интересно, могут и пропустить.

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

294. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  –1 +/
Сообщение от Аноним (-), 09-Июл-13, 14:01 
> нужно. потому что куча народу о ней не в курсе.

Mmaped -> must die. Нафиг надо kv-базу с лимитом на 4Гб. Шутка юмора не понята.

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

300. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 09-Июл-13, 14:13 
> Mmaped -> must die. Нафиг надо kv-базу с лимитом на 4Гб. Шутка
> юмора не понята.

см. выше.

впрочем, я готов побиться об заклад, что ты не только не понимаешь места и способы применимости k/v, но и никогда не работал с реально большими объёмами данных. поэтому твое мнение — из разряда «я админ локалхоста, я точно знаю, как надо админить парк из 9e+3 машин!»

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

302. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  –1 +/
Сообщение от Аноним (-), 09-Июл-13, 14:23 
> впрочем, я готов побиться об заклад, что ты не только не понимаешь
> места и способы применимости k/v,

Какой высокопарный апломб. Иди расскажи разработчикам файловых систем с верхним лимитом на экзабайты какие они лохи :). А то они тоже что-то маппят путь к файлу в данные файла. По сути подвид K/V вполне себе. Хоть и оптимизированный под специфичное применение. Ну ты сам нарывался своими generic заявами за "k/v вообще" чтобы тебя так боднули. Ты и сам такие подъ...ки любишь вроде. А тут моя очередь :P.

Как раз k/v прекрасны в том числе и
1) Низким оверхедом.
2) Высокой скоростью даже при диком количестве записей.

У хэш-таблиц например вообще время работы - O(1). Замечательная штука чтобы туда вагон записей сгрузить.

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

334. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от AlexAT (ok), 10-Июл-13, 00:02 
> Как раз k/v прекрасны в том числе и
> 1) Низким оверхедом.
> 2) Высокой скоростью даже при диком количестве записей.

Именно. И это нужно там, где это нужно. В остальных случаях за использование KV придётся платить изобретанием велосипедов и колёс. К сожалению, очень часто KV юзают там, где не стоило бы.

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

341. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 10-Июл-13, 02:47 
> Именно. И это нужно там, где это нужно.

Вообще случаев где key/value хватит - довольно много. Если не заморачиваться искусственным переусложнением сущностей.

> В остальных случаях за использование KV придётся платить изобретанием
> велосипедов и колёс.

Вот только в насоветованных вами решениях изобретение великов типа экранирования и прочая - вообще сразу подразумевалось по дефолту для ВСЕХ случаев.

> К сожалению, очень часто KV юзают там, где не стоило бы.

SQL не менее часто юзают где он нафиг не упал. А еще - именно грамотно им пользоваться умеет очень мало народа. Поэтому тут вам и вагон скуль-иньекций в каждой дырке, и адские тормоза казалось бы простых как топор операций, и дикие прелести жизни.

Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами. Они там 126 столбцов завели. И хранили, итить, цвет шрифта как отдельную колонку в таблице. В k/v они бы по крайней мере за...сь так извращаться и поневоле пришли бы к более разумным решениям :). Ах да, при чем тут sql.ru? Мускул при попытке создать ЭТО - сдуревал и выдавал ошибку, разумеется :)

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

344. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от AlexAT (ok), 10-Июл-13, 07:23 
> Вот только в насоветованных вами решениях изобретение великов типа экранирования и прочая
> - вообще сразу подразумевалось по дефолту для ВСЕХ случаев.

Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный код при правильной его организации. Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано), то скорее всего все запросы изначально будут в виде prepared statements, и никакого явного экранирования не потребуют.

> Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами.

В .ru вообще много примеров использования разных вещей безмозглыми существами... но это ни о чем не говорит.

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

345. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 10-Июл-13, 11:59 
> Да что вы уперлись в это экранирование? Экранирование запроса - это минимальный
> код при правильной его организации.

Тем не менее, это дополнительные действия. Если данных много, их экранирование/деэкранирование может занять вполне заметное время. Хороший k/v вообще хранит любые данные. Что означает отсутствие таких проблем by design. Намного лучше когда дизайн failsafe сам по себе, да еще и скорость не просядет лишний раз.

> Более того - если мы говорим о переходе с KV на SQL (там, где это оправдано),

С таким же успехом можно говорить и о обратном переходе там где SQL запихнули "потому что модный buzzword же". И тут вдруг ВНЕЗАПНО до некоторых стало доходить что NoSQL может быть инересной опцией в плане скорости :). В основном потому что там геморно делать неоптимальные запросы.

> то скорее всего все запросы изначально будут в виде prepared statements, и
> никакого явного экранирования не потребуют.

Не, куча допущений - это здорово, конечно, но я не вижу - что даст такой маневр в общем случае кроме лишнего головняка и тормозов. SQL достаточно сложный ЯП, грамотно делать запросы на оном умеет очень небольшое количество народа. А чтобы оно еще и работало со скоростью хоть немного похожей на оную у key-value баз - это вообще рокетсайнс.

Я конечно понимаю рвение везде пихать SQL, но обычно как раз это приводит к тому что его пытаются сосватать даже туда где он нафиг не упал. А потом начинаются удивления - "ой, как это - файрфокс начинает тормозить если вы много сайтов посетили?!". И догадайтесь, блин, во что оно уперлось. В сиквельную базу, итить. Во как.

>> Как-то на sql.ru был просто эталонный пример использования SQL безмозглыми существами.
> В .ru вообще много примеров использования разных вещей безмозглыми существами... но это
> ни о чем не говорит.

Хорошо, я могу и иной пример. А вот в амарок2 активно сватали мускуль. Я например совершенно не понял зачем мне в системе здоровенный демон от навороченной базы и просто снес все это безобразие нафиг. Они бы еще пэхэпэ и апач приволокли, блин.

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

256. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  –1 +/
Сообщение от бедный буратино (ok), 09-Июл-13, 10:18 
>> Велик уровня беркелейской либы придется делать довольно долго. Это довольно продуманная
>> и мощная библа, сами вы будете довольно долго пыхтеть, выписывая аналогичные
>> апи. И документировано неплохо.
> я уже как-то даже подустал: LMDB: http://symas.com/mdb/

О, любопытно. Токийско-киотские кабинеты мне чем-то не понравились, уже даже не помню чем, давно было. А это вроде милое. Не такое милое, как питоновская shelve с её подложками, но всё равно милое. :)

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

288. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 09-Июл-13, 13:38 
это замена для сишников сотоварищи. нам бидон как-то не в тему будет. собственно, замена именно BDB, потому что у них очень похожие API.

а так — ещё hamsterdb есть, например. гуглевый leveldb. tdb из самбы на крайний случай. сотни их.

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

293. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  –1 +/
Сообщение от Аноним (-), 09-Июл-13, 13:58 
> собственно, замена именно BDB, потому что у них очень похожие API.

Только bdb насколко я помню адресным пространством не лимитирована. А для 32-битных платформ лимит в 4Gb может больно шибануть ручкой грабель в лою.

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

295. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от arisu (ok), 09-Июл-13, 14:02 
>> собственно, замена именно BDB, потому что у них очень похожие API.
> Только bdb насколко я помню адресным пространством не лимитирована. А для 32-битных
> платформ лимит в 4Gb может больно шибануть ручкой грабель в лою.

если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то делаешь очень неправильно.

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

301. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 09-Июл-13, 14:14 
> если у тебя несколькогигабайтная база в k/v — ты, мне кажется, что-то
> делаешь очень неправильно.

Жду когда ты себе диск протрешь нулями, а то файловая система тоже маппит ключ "путь и имя файла" в значение "данные файла" :)

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

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

+100500000000000000000000000000000000000000000000000000000000000000000000

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

346. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 10-Июл-13, 12:02 
> +100500000000000000000000000000000000000000000000000000000000000000000000

А ты уже заменил файловую систему на сиквельную базу? А то микрософтушка что-то вон ниасилил :)

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

173. "Berkeley DB переведён на лицензию AGPLv3, что привело к проб..."  –1 +/
Сообщение от linux must __RIP__ (?), 08-Июл-13, 16:25 
>> очень удобная реализация деревьев + сторадж с поддержкой транзакций + (как говорили)
>> может выполняться в kernel space.. + в качестве примеров идет чуть
>> ли не кусок журналируемой файлухи.. - очень не плохой вариант..
> Для любителей делать троллейбусы из буханок хлеба? Так они свой велосипед напишут,
> так даже интереснее.

а в чем проблема - они разнесли 2 уровня абстракции - контейнер с транзакциями и журналом и таблицы в этом контейнере. Теперь можно делать что угодно - к слову файловая система (ее часть относящаяся к метаданным) это просто таблицы key->value. Да и данные по сути это дерево которое где-то хранить надо..


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

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

Не согласен. Вполне позитивная либа с позитивными разработчиками. Имел счастье когда-то взаимодействовать с ними, понравилось. Sleepycat был вполне прикольной компанией с весьма приятным народцем. И апи у либы довольно мощное и логичное.

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

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

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




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

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