Исходное сообщение
"Berkeley DB переведён на лицензию AGPLv3, что привело к проб..." Отправлено Аноним, 08-Июл-13 16:17
> И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set. Ты издеваешься или как? Можно взять готовое решение которое работает быстро и безграбельно, а можно др@читься с выписыванием костылей самому + просесть в скорости. Нафиг надо такое "счастье"? В нормальном виде сие должны были делать по людски разработчики скулайта, предоставив простое и низкоуровневое апи к его фактической реализации хранилища. Но это не было их целью, как соедует из названия. У них SQL головного мозга и баста. Если тебе нравится забивать гвозди микроскопом - флаг тебе в руки делать key-value из скулайта. А мне если уж AGPL так сильно дорогу перейдет, я какой-нить токийский кабинет возьму скорее. И да, обычно в таких базах можно выбирать довольно низкоуровневые параметры стоража, которые иногда довольно сильно роялят. В частности - хэш-таблица, б-дерево, etc. Они разные по свойствам и в зависимости от ситуации - оптимальнее или так, или эдак. А в скулайте такое вообще хрен выберешь вообще. > А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать. Я не собираюсь бросать все и подрываться изучать новый ЯП (SQL) на уровне супергуру который умеет запросы профайлить. Тем более что там IIRC нет относительно низкоуровневых опций управления логикой стоража на уровне самых основ технологий хранения. А иногда удачный выбор таких опций может скорость в разы поднять. На скулайте придется пыхтеть в разы больше, а скорость будет в разы ниже.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> И в SQL-based KV store тоже - потому что вся обертка делается в ->get / ->set. > Ты издеваешься или как? Можно взять готовое решение которое работает быстро и > безграбельно, а можно др@читься с выписыванием костылей самому + просесть в > скорости. Нафиг надо такое "счастье"? > В нормальном виде сие должны были делать по людски разработчики скулайта, предоставив > простое и низкоуровневое апи к его фактической реализации хранилища. Но это > не было их целью, как соедует из названия. У них SQL > головного мозга и баста. Если тебе нравится забивать гвозди микроскопом - > флаг тебе в руки делать key-value из скулайта. А мне если > уж AGPL так сильно дорогу перейдет, я какой-нить токийский кабинет возьму > скорее. > И да, обычно в таких базах можно выбирать довольно низкоуровневые параметры стоража, > которые иногда довольно сильно роялят. В частности - хэш-таблица, б-дерево, etc. > Они разные по свойствам и в зависимости от ситуации - оптимальнее > или так, или эдак. А в скулайте такое вообще хрен выберешь > вообще. >> А скорость работы будет зависеть от рук. Для KV стора вообще можно запросы предкомпилировать. > Я не собираюсь бросать все и подрываться изучать новый ЯП (SQL) на > уровне супергуру который умеет запросы профайлить. Тем более что там IIRC > нет относительно низкоуровневых опций управления логикой стоража на уровне самых основ > технологий хранения. А иногда удачный выбор таких опций может скорость в > разы поднять. На скулайте придется пыхтеть в разы больше, а скорость > будет в разы ниже.
	Введите код, изображенный на картинке: