The OpenNET Project / Index page

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



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

Оглавление

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

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


230. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  –1 +/
Сообщение от northbear (??), 09-Июл-13, 02:17 
BerkeleyDB, пол-программы переписывать? 0_о Вы похоже думаете, что это что-то типа MySQL, да?

Если вам для того, чтобы сменить berkeleydb на тот же sqlite, надо переписать пол-программы, то у вас руки не с того места растут и вас к компьютерам подпускать нельзя.

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

232. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 09-Июл-13, 02:26 
> BerkeleyDB, пол-программы переписывать?

а что такого? вот берём — и используем API без очередного дурацкого слоя обёртки.

да-да-да, я знаю, МегаПрограммисты не останавливаются, пока не напишут 13 обёрток над любым апи (а потом добавят ещё несколько — на всякий случай).

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

237. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от northbear (??), 09-Июл-13, 02:47 
> а что такого? вот берём — и используем API без очередного дурацкого
> слоя обёртки.

:facepalm: Дай угадаю... лабы по программированию на три балла, не больше, да?

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

238. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от arisu (ok), 09-Июл-13, 02:53 
> :facepalm: Дай угадаю... лабы по программированию на три балла, не больше, да?

ну, я же не настоящий сварщик, я не считаю, что все проблемы можно решить, добавив ещё один слой Очень Полезной Абстракции.

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

245. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  –1 +/
Сообщение от Аноним (-), 09-Июл-13, 03:16 
> ну, я же не настоящий сварщик, я не считаю, что все проблемы
> можно решить, добавив ещё один слой Очень Полезной Абстракции.

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

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

247. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 09-Июл-13, 03:18 
что характерно — очень часто это действительно вполне нормальное решение. но у вантузоидов от программ, которые на выходе дают другие программы, обостряется чувство собственной неполноценности.
Ответить | Правка | Наверх | Cообщить модератору

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

Ога. Особенно клево, когда оно записывает туда тексты, пропущенные через пятистрочные регекспы, а потом запускают с рутовыми правами. Не один SQL инъекциями богат...

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

251. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от arisu (ok), 09-Июл-13, 03:33 
что, бедняша, локалхост так навернул? оно завсегда если мозгов нет — то падает.
Ответить | Правка | Наверх | Cообщить модератору

327. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 09-Июл-13, 20:50 
> что, бедняша, локалхост так навернул? оно завсегда если мозгов нет — то падает.

Не, ну вообще-то у него есть пойнт. Я таким манером пару раз весьма изящно дурачил скрипты автоматического процессинга данных, как ты понимаешь, далеко не все в курсе про Бобби Тэйблса и его коллег по цеху :)

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

328. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 09-Июл-13, 21:57 
ну так специально можно и МПХ сломать, лишь бы цель такая стояла.
Ответить | Правка | Наверх | Cообщить модератору

329. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 09-Июл-13, 22:46 
> ну так специально можно и МПХ сломать, лишь бы цель такая стояла.

У скуля как раз неприятная особенность в том что он слишком много всего умеет by default. С другой стороны, нормальной k/v базе совершенно все-равно что получить на вход и что будет данными. Это избавляет от массы головняка.

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

336. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от AlexAT (ok), 10-Июл-13, 00:15 
Прелесть кв не в блобятине - на блобятину можно и скуль заточить (уже ж говорил - prepared statement, и никаких проблем). Прелесть в сравнительно шустром доступе к данным по ключу. С другой стороны, скуль и KV тихонько сливаются в экстазе - вон, NDB или TokuDB (TokuMX, если хотите NoSQL), и разница между ними становится в один парсер. Да и для InnoDB NoSQL access уже запилили. С inmemory тот же Inno/Toku не сравнить, конечно, но мы и не о inmemory говорим. А NDB неплохо так масштабируется, но он явно не эмбеддед :)

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

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

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

Прелесть - в том что k/v
1) Затачивать не надо - ему индиффирентно чего жрать с самого начала в большинстве реализаций.
2) Оверхеда на это ноль.
3) Сам по себе он быстрый.
4) Иньектить во многие реализации вообще совсем не получится.
5) Просто для понимания програмером. Если приходится вычитывать 1005000 записей - програмер быстро замечает неоптимальность. А в скуле он даже и не узнает о том что его select * from немеряная_таблица - это плохо. Потому что на его тестовом серванте с 10 записей и так катило. А вот когда это выкатят в продакшн - тут то и начнется конкретное ололо, при том не сразу, что особенно доставляет :)

> (уже ж говорил - prepared statement, и никаких проблем). Прелесть в
> сравнительно шустром доступе к данным по ключу.

Ну спасибо, Капитан. Это не просто "сравнительно шустрый" доступ. Это близко к наиболее быстрому с теоретической точки зрения для данной технологии стоража. Потому что это лобовая команда сторажу "дай вот это". Для b-дерева или хэш-таблицы это довольно быстрая и дешевая операция. Тот же токийский кабинет напрмер гарантирыет всего 2 запроса к диску на успех и 1 запрос к диску на неуспех.

И, кстати, к вопросу о размере и гектарах. В б-деревьях скорость относительно числа записей падает логарифмически, т.е. довольно медленно. В хэш-таблицах она вообще в среднем по больнице константа. По поводу чего сам по себе k/v или нечто подобное можно с чистой совестью юзать под очень масштабные применения. Майкрософтушка вон юзает какой-то относительно низкоуровневый ESE для AD о десятках миллионов объектов и Exchange с гигазами почты - и никакого вам скуля.

И если уж на то пошло - безбашенно накормить скуль запросом который где-то там внутри проелозит весь диск и все 100 000 000 записей - фигня вопрос. Достаточно безбашенено написать запрос и вытаскивание единственной записи будет занимать полчаса. В случае k/v сие делать неудобно, чисто технически. Програмер очень быстро заметит что его алгоритмика оставляет желать, в отличие от скуля, где это будет зарыто под слоем абстракций, которые хорошо понимает далеко не каждый кто использует SQL.

> С другой стороны, скуль и KV тихонько сливаются в экстазе - вон, NDB или TokuDB
> (TokuMX, если хотите NoSQL), и разница между ними становится в один парсер.

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

> Да и для InnoDB NoSQL access уже запилили. С inmemory тот же Inno/Toku
> не сравнить, конечно, но мы и не о inmemory говорим.

Как бы это сказать? Хороший key-value на быстром носителе типа SSD или тем более в RAM (cache hit или просто in-memory база) покажет именно эти самые свойства. Собственно in-memory и делают по каким-то таким технологиям, вся разница лишь в том что они обычно не имеют дело с диском напрямую и по этому поводу возможны некоторые послабления и упрощения иногда.

> А NDB неплохо так масштабируется, но он явно не эмбеддед :)

Ну если капитанить то у САБЖА кстати тоже есть SQLный фронтэнд, так что он и так и сяк умеет, правда тех кто юзал бы его через скуль я не видел, но при желании это можно :).

И если уж на то пошло, самому по себе key/value нет никаких причин не масштабироваться. Вон файловые системы до терабайтов масштабируются спокойно. Да и многие иные смогут. А чего б им? Лежащая в основе технология не чувствительна или мало чувствительна к размеру стоража сама по себе. Это програмер и его логика может облажать уже. Ну так оно и в SQL с нубами и select * тоже облажается. При том написать select * явно проще чем написать код явно читающий 100 000 записей, так что на SQL тормозные запросы как раз правило а не исключение :)

> Имхо будущее за гибридными движками хранилищ, к которым можно обратиться и так
> и сяк, в зависимости от потребности.

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

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

354. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +1 +/
Сообщение от arisu (ok), 10-Июл-13, 16:15 
> А в скуле он даже и не узнает
> о том что его select * from немеряная_таблица — это плохо.

это не программер, это быдлокодер. быдлокодер что угодно испортит.

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

360. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от Аноним (-), 11-Июл-13, 18:44 
> это не программер, это быдлoкодер. быдлoкодер что угодно испортит.

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

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

362. "Berkeley DB переведён на лицензию AGPLv3, что привело к..."  +/
Сообщение от arisu (ok), 11-Июл-13, 21:20 
ой, как будто на k/v не делают таких ужасов, когда смотришь и офигеваешь.
Ответить | Правка | К родителю #360 | Наверх | Cообщить модератору

254. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  +/
Сообщение от AlexAT (ok), 09-Июл-13, 07:30 
Да даже тот же MySQL Embedded можно встроить без особых проблем. Вопрос только в том, что весить оно будет бугага сколько...
Ответить | Правка | К родителю #230 | Наверх | Cообщить модератору

298. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  +/
Сообщение от Аноним (-), 09-Июл-13, 14:06 
> Да даже тот же MySQL Embedded можно встроить

Но лучше ты его себе куда-нибудь встрой. Ибо сдавать экзамен на пилотирование боинга при том что я всего-то на скутере хотел погонять - как-то больно недружественно ко мне получается.

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

333. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  +/
Сообщение от AlexAT (ok), 10-Июл-13, 00:00 
А, ну так и скажите - порог вхождения не все осиляют. Это да, факт.
Другое дело, когда места посадить боинг / поставить хаммер нет - вот там скутер оправдан. Но в приличном ряде случаев монопенисуально.

PS. Не об IT: на скутеры тоже права вводят. К чему бы это? Отсутствие порога вхождения провоцирует поведение на дорогах? :)

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

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

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

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

Может ли сиквель быть не слишком тормозным? Может. Если найти специалиста по ракетным наукам, который собаку на этом съел. Проблема только в том что такие спецы - редки как пингвины в пустыне Сахара и стоят совершенно диких денег. Поэтому их обычно не оказывается в нужном месте в нужное время. Результат достаточно плачевен.

> Другое дело, когда места посадить боинг / поставить хаммер нет - вот
> там скутер оправдан. Но в приличном ряде случаев монопенисуально.

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

> PS. Не об IT: на скутеры тоже права вводят. К чему бы
> это? Отсутствие порога вхождения провоцирует поведение на дорогах? :)

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

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

352. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  +/
Сообщение от AlexAT (ok), 10-Июл-13, 14:22 
> Ну как бы да, глупое применение k/v тоже возможно. Но в современном
> мире намного больше глупых применений SQL, так что как видишь, скутерам
> в последнюю очередь достается - они далеко не основной источник проблем
> на дорогах :P.

Автомобилей тоже больше, чем скутеров...

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

361. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  +/
Сообщение от Аноним (-), 11-Июл-13, 18:45 
> Автомобилей тоже больше, чем скутеров...

А автомобиль по управлениию ближе к скутеру чем к боингу. Ы?

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

297. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  –1 +/
Сообщение от Аноним (-), 09-Июл-13, 14:05 
> BerkeleyDB, пол-программы переписывать? 0_о Вы похоже думаете,

Я не "думаю", я видел эту либу лично и даже в ее кишках немного копался по технической необходимости. Это мощная либа с рядом фич, прямых аналогов которых у остальных нет.

Я охотно посмотрю как вы перепишете их апи курсоров например. А оно у "конкурентов" есть? И именно такое же? Даааа?

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

358. "Berkeley DB переведён на лицензию AGPLv3, что привело к вопр..."  +/
Сообщение от northbear (??), 11-Июл-13, 00:24 
Ну, раз вы покопались в кишках, то расскажите нам, чем уникальны курсоры в BDB.

На sql-платформах быстро переболели модным функциональным поветрием в виде курсоров. В BDB, как видите, оно осталось, за неимением другого механизма доступа к записям у которых ключи совпадают...
Если вам реализация api курсоров кажется сложной, почитайте про итераторы.

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

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

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




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

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