| 1.1, Аноним (-), 22:21, 13/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Чем оно отличается от OpenLDAP? С апстримом синхронизируется или нет?
| | |
| |
| |
| |
| 4.33, Michael Shigorin (ok), 16:25, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
 >> OSSDEVCONF-2016
> Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL
Кстати, приезжайте в этом году :)
И ещё кстати: заметил сборку reopenldap-2.4.44 для эльбруса, не расскажете? (начиная с того, что нынче с версионированием)
| | |
| |
| 5.35, erthink (ok), 17:03, 14/08/2017 [^] [^^] [^^^] [ответить] | +1 +/– |  Постараюсь Но увы обещать не могу Тут вот надо-бы в Брюссель ехать на https... большой текст свёрнут, показать | | |
| |
| 6.52, Shtirlitsus (??), 15:05, 16/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > Если кратко, то это не я, а ребята из РедСофт.
клевета. мы под Эльбрус ReOpenLdap не собирали.
| | |
| |
| 7.55, erthink (ok), 17:12, 16/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> Если кратко, то это не я, а ребята из РедСофт.
> клевета. мы под Эльбрус ReOpenLdap не собирали.
Пардон, у меня "под подозрением" были только вы ;)
Точнее я был уверен...
Больше идей нет, пакетов не видел, и патчей тоже.
Причем там были мелкие гадости, которые поправил кажется весной.
Чел собирал с libc-muls, кажется для ARM и там что-то повылазило (git log --oneline | grep musl).
Поэтому для Эльбруса оно в лоб не собралось-бы.
Но если будут вести - маякните pls.
| | |
|
|
|
|
|
|
| 1.5, Аноним (-), 00:08, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +6 +/– | |
> В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями.
Речь вот об этой наркомании? :
int ldap_search_ext(
LDAP *ld,
char *base,
int scope,
char *filter,
char *attrs[],
int attrsonly,
LDAPControl **serverctrls,
LDAPControl **clientctrls,
struct timeval *timeout,
int sizelimit,
int *msgidp );
| | |
| |
| 2.11, erthink (ok), 07:41, 14/08/2017 [^] [^^] [^^^] [ответить] | +1 +/– | gt оверквотинг удален Нет В этом API просто много параметров и пугающие LDAPC... большой текст свёрнут, показать | | |
| |
| 3.28, Аноним (-), 14:08, 14/08/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется "логично и корректно", а то что я привел - уже писали долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска.
Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и знают как надо библиотечное api проектировать для Си.
А то что там в коде можно найти ещё более лютый ппц - я ни минуты не сомневаюсь.
| | |
| |
| 4.37, erthink (ok), 17:38, 14/08/2017 [^] [^^] [^^^] [ответить] | +3 +/– | ldap_search просто вызывает ldap_search_ex подставляя кучу NULL Использоват... большой текст свёрнут, показать | | |
|
|
|
| |
| 2.9, Аноним (-), 06:25, 14/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование bdb)
| | |
| |
| 3.10, erthink (ok), 07:16, 14/08/2017 [^] [^^] [^^^] [ответить]
| +3 +/– |
> FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование
> bdb)
Да, примерно так, но хуже.
На пробах нагрузку держал только OpenLDAP, все остальные на один-два порядка меньше.
Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012, и еще каких-то форточек), но результат был стабильно жуткий.
| | |
| |
| 4.29, PnDx (ok), 14:21, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Поставить OpenLDAP+HDB|MDB репликой к 389DS|FDS мульти-мастеру?
1. Управляемость.
2. Нагрузочная способность.
3. Профит.
(4. Нюансы: не поддерживает навороченных хэшей (в 389DS всё на плагинах) и иных плюшек.)
| | |
| |
| 5.30, erthink (ok), 15:35, 14/08/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Увы, это все нереально 389DS не справляется с требуемой нагрузкой Если было-бы... большой текст свёрнут, показать | | |
| |
| 6.41, PnDx (ok), 20:09, 14/08/2017 [^] [^^] [^^^] [ответить] | +/– | Да, и в моём случае корень проблемы даже не столько в BDB как таковой на чтении... большой текст свёрнут, показать | | |
|
|
| 4.34, Michael Shigorin (ok), 16:28, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012,
> и еще каких-то форточек), но результат был стабильно жуткий.
В одном федеральном органе такой AD держался на сильно специальном контракте по поддержке -- интересно, что там сейчас...
| | |
| |
| 5.63, arkan (?), 13:22, 17/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
>> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012,
>> и еще каких-то форточек), но результат был стабильно жуткий.
> В одном федеральном органе такой AD держался на сильно специальном контракте по
> поддержке -- интересно, что там сейчас...
Не знаю про какой Вы там федеральный орган, но я лично участвовал во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании
Результаты были вполне хорошие но вот с управляемостью все на самописных скриптах кастылях и тому подобном оставляла желать лучшего
Да и специалистов как то особо и не нашлось кто отвечал бы чисто за это направление.
На сколько я знаю сейчас там этот OpenLdap стоит как дополнительный под какие то там задачи
| | |
| |
| 6.90, Michael Shigorin (ok), 19:36, 22/08/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Не знаю про какой Вы там федеральный орган, но я лично участвовал
> во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании
Вообще LDAP -- не замена AD (который надмножество покорёженного LDAP), это самбу смотреть надо; например, http://altlinux.org/SambaDC (кстати, у нас недавно завелось и на эльбрусе).
| | |
|
|
|
|
| 2.12, erthink (ok), 08:15, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Если OpenLDAP не подошел может быть было лучше эти посмотреть:
> * http://directory.apache.org/
> * http://directory.fedoraproject.org/
> ?
У OpenDJ или 389DS будет шанс обогнать ReOpenLDAP по скорости только при замене движка хранения на libmdbx.
Но OpenDJ -- это ява и тамошние ценители седеют просто глядя на код LMDB/libmdbx, даже через JNI.
А 389DS очень сильно заражен Berkeley DB. Дрянная днк BDB там прослеживается в половине проекта и для возможности подключения другого backend-а нужно проделать большую работу = вычистить хвосты BDB и сформировать достаточный внутренний API для plugable подсистемы хранения.
| | |
| |
| 3.14, Ph0zzy (ok), 08:50, 14/08/2017 [^] [^^] [^^^] [ответить]
| –1 +/– |
 т.е. проблема именно в неприятии java?
а значит ApacheDS пролетает из-за этого же?
| | |
| |
| 4.17, erthink (ok), 09:17, 14/08/2017 [^] [^^] [^^^] [ответить] | +2 +/– | Что значит неприятие Java Неприятие кем Пролетает где Безотносительно Apach... большой текст свёрнут, показать | | |
| 4.23, andy (??), 10:29, 14/08/2017 [^] [^^] [^^^] [ответить]
| +4 +/– |
Это не проблема, это реалии жизни. Потому, что большая часть того,
что пишется на java, являет собой кучу гуано.
| | |
|
| |
| 4.26, erthink (ok), 11:40, 14/08/2017 [^] [^^] [^^^] [ответить] | +1 +/– | С Mavibot в работе я не сталкивался Судя по описанию его устройство очень близк... большой текст свёрнут, показать | | |
| |
| 5.27, Ph0zzy (ok), 12:37, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
Последние несколько лет сильно за темой не слежу, так что эта новость первая, которую вижу по данной тематике. Складывается впечатление, что по теме застой. Так что отсутствие свежих бенчмарков показательно.
| | |
| |
| 6.31, erthink (ok), 15:56, 14/08/2017 [^] [^^] [^^^] [ответить] | +3 +/– | Я бы не сказал что застой, точнее он только в OpenLDAP причины в моем понимании... большой текст свёрнут, показать | | |
|
|
|
|
|
| 1.13, Аноним (-), 08:44, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
>хочется ответить на частый вопрос "Почему нет пакетов?"
хорошо, а почему нет ебилдов?
| | |
| 1.15, Аноним (-), 09:06, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?
| | |
| |
| 2.18, erthink (ok), 09:23, 14/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?
Повторю еще раз = скорость.
Чтобы у 389DS были шансы сравниться с OpenLDAP или ReOpenLDAP нужно вместо Berkeley DB использовать https://github.com/leo-yuriev/libmdbx или хотя-бы какой-нибудь WiredTiger.
Причем я полностью согласен, что 389DS сейчас имеет гораздо более красивый и надежный код. Но вот backend хранения - из прошлого века.
| | |
| |
| 3.22, Аноним (-), 10:28, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
А вы пробовали с Red Hat на эту тему поговорить (разумеется с бенчмарками и прочими пруфами)?
| | |
| |
| 4.25, erthink (ok), 11:00, 14/08/2017 [^] [^^] [^^^] [ответить] | +2 +/– | Говорить по-сути не о чем Проблема в другом, и уже давно как бревно в глазу У ... большой текст свёрнут, показать | | |
|
|
|
| |
| 2.88, erthink (ok), 00:23, 21/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Бурханыч еще и в сторону LDAP развивает Интернет?
Слоупок я, дошло о чем спрашивали ;)
Может и развивает, но мне об этом ничего не известно.
Если говорить о ReOpenLDAP, то эта работа была сделана исключительно для решения проблем возникших (достаточно неожиданно) при внедрении одного из решений Петер-Сервис внутри МегаФона.
С сентября 2016 проект не аффинирован с какой-либо коммерческой структурой (не считая публичных сервисов: github, travis-ci и т.п.).
| | |
|
| 1.21, Ph0zzy (ok), 10:25, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
может быть, если бы вы в своих репозиториях в гитхабе использовали другой язык, удалось привлечь внимание большего количества разарботчиков?
| | |
| |
| 2.24, erthink (ok), 10:40, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Да, конечно, это очевидно.
Но "не все так однозначно". Собственно главная проблема унаследована от OpenLDAP.
Исходный код кошмарен с точки зрения читаемости и подводных камней. Эффективно с ним работать может только авторы, точнее сам Ховард и может-быть кто-то еще.
Всем остальным приходиться тратить массу времени на понимание написанного, особенно всех взаимосвязей и side effects.
Поэтому, на самом деле, вне зависимости от языка и прочих ритуалов привлечения внимания, в ReOpenLDAP не будет много больше разработчиков чем в исходном OpenLDAP.
| | |
|
| |
| 2.36, erthink (ok), 17:16, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– | |
Исходная цель ReOpenLDAP была попроще = навести минимальный порядок и поправить баги мешающие (мягко говоря) эксплуатации.
Ну и Libre тогда только у офиса была, стереотипов еще не было )
| | |
|
| |
| |
| 3.40, erthink (ok), 19:01, 14/08/2017 [^] [^^] [^^^] [ответить]
| +/– | |
> fix: не rdbms конечно, а dbms
Начиналось с другого, совсем.
Просматривался вариант реализовать одну из подсистем с участием LDAP-сервера.
Кроме этого, в "принципе не помешал-бы" некий работающий LDAP-blackbox.
Протестировали производительнось, прошел только OpenLDAP.
Проблемы всплыли много позже, и тогда меня позвали починить...
Собственно, что я перессказываю - там выше есть ссылка на запись доклада.
А где-то там у Стаса рядом есть запись и доклада с 2015.
Но если абстрагироваться от истории, то inmemory+wal конечно подходит.
Но тогда Костин tarantool был ещё не так крут/готов, а главное - OpenLDAP работал в тестах и никто не ожидал "напильника" в два года.
| | |
| |
| 4.42, лютый жабист__ (?), 11:52, 15/08/2017 [^] [^^] [^^^] [ответить]
| –3 +/– |
Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо было ждать :D итого архитектора на мыло, трудозатраты не оценили путём, два года ваяли велосипед
| | |
| |
| 5.43, erthink (ok), 12:47, 15/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо
> было ждать :D итого архитектора на мыло, трудозатраты не оценили путём,
> два года ваяли велосипед
У вас есть неточность - на java НЕТ промышленных (и не промышленных) решений которые могут заменить или как-то конкурировать с ReOpenLDAP. Даже без репликации они уступают в 5-10 раз (точнее сказать сложно: разное железо, схемы, характер запросов и т.д.) при условии работы in-memory. А как только требуется фиксация на диске, то java неожиданно заносит и все тонет в IOPS.
Далее, если разобраться, то все "промышленные решения на яве", на деле оказываются чуть менее чем XY-ней, примерно везде где нужна производительность (а не "кони в вакууме" или "фабрики фабрик для фабрик молотков"). А все исключения из этого наблюдения устойчиво попадают в шаблон: сверху на яве рисуются кнопочки и "IB-розочки", а снизу через JNI все делает C/C++.
Причем на 20% в этом виновата сама Java, с "парой чемоданов батареек" в виде виртуальной машины, сборки мусора и т.п.
И на 80% - экосистема, где здравый смысл принесен в жертву религии шарообразных абстракций, паттернов и некого стиля.
Вот только уточню: в огромной массе других случаев java - отличный язык и технология, в том числе более дешевый.
| | |
| |
| 6.44, erthink (ok), 13:51, 15/08/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Чуть наброшу по теме Java.
Все ошибаются, и нисколько я не исключение. Поэтому, если (вдруг) все-таки есть какие-то java-решения на замену ReOpenLDAP, то я вам советую/прошу предложить их в billing.ru. Может даже поучаствовать во внедрении.
Жабу там беззаветно любят, если не ошибаюсь - уже лет 15.
Однако, все-же есть риски что не примут (пошлют). Ибо уже года 3 (могу ошибаться) срывают сроки релизов из-за того, что "промышленные решения на java" работают чуть медленнее чем надо (а чертовы мегагерцы перестали расти).
Причем, там же можно будет выяснить (лицом к лицу) актуальность общеизвестных и как-бы основных причин (руки из попы, люди-снежинки, танцорам что-то мешает) плохих java-показателей. Ну и показать "как надо".
Короче, всячески рекомендую.
| | |
| |
| |
| 8.59, Аноним (-), 10:31, 17/08/2017 [^] [^^] [^^^] [ответить] | +4 +/– | В способности тру-жабистов нагрузить в полку все 100500 ядер системы даже обычны... текст свёрнут, показать | | |
|
|
|
|
|
|
|
| |
| 2.47, erthink (ok), 12:09, 16/08/2017 [^] [^^] [^^^] [ответить]
| +2 +/– | |
Ох, судя по описанию java-вакансии в Петер-Сервисе еще не все пальцы отгорели от засовывания highload в розетки типа ElasticSearch и Cassandra :)
И причины появления http://www.scylladb.com не вразумили, жаль.
| | |
| 2.49, лютый жабист__ (?), 12:26, 16/08/2017 [^] [^^] [^^^] [ответить]
| –3 +/– | |
> На самом деле платят и ищут профи.
По вакансии не скажешь, что ищут профи. "Ожидания" уровня простого жабакодера. з/п не указана. Ещё и Питер.
"правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++."
Ты опять неправ. Про утилизацию железа уже писал. Из личных наблюдений сишные Постгрес, Монго, Оракле на например 12-ядернике дальше 1-2 ядер НИКОГДА не вылазят. Мои жабные поделки - легко, иногда даже без доп телодвижений (те же Collections из core многопоточны из коробки).
Кстати, из общения с продуктами Positive Technologies. SIEM полный шлак по сравнению со ВСЕМИ рассмотренными конкурентами. Сканер сети шлак, а цена космос. Только менеджеры говорливые, обещают что "вот-вот всё станет круто". Так что предлагаю авторитетом не давить ;)
| | |
| |
| 3.50, erthink (ok), 13:10, 16/08/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Ну я уже понял что вы у нас коренной уникум из defaultcity и за еду в Питер не... большой текст свёрнут, показать | | |
| |
| 4.51, лютый жабист__ (?), 14:42, 16/08/2017 [^] [^^] [^^^] [ответить]
| –5 +/– |
Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому что нормальные прогеры пишут сразу в машинных кодах. И субд и распределенные системы. А си ваше тормозит и глючит, особенно с -O3, знаем, плавали.
| | |
| |
| 5.54, erthink (ok), 17:05, 16/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
> Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому
> что нормальные прогеры пишут сразу в машинных кодах. И субд и
> распределенные системы. А си ваше тормозит и глючит, особенно с -O3,
> знаем, плавали.
Да, понимаю.
Но вы держитесь, нас всех когда-нибудь вылечат ;)
Короче, шанс еще есть, держитесь!
| | |
| 5.58, bOOster (ok), 06:23, 17/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
 Гражданин, в твоем кривом мозгу не созрело что JAVA изначально тоже писана на C? И собирается с теми-же -O ключами?
"де$илы, $ля" (с)
| | |
| |
| 6.61, лютый жабист__ (?), 11:48, 17/08/2017 [^] [^^] [^^^] [ответить]
| –2 +/– | |
>JAVA изначально тоже писана на C
И посмотри сколько ДЫРИЩ в каждой версии. Жду не дождусь когда жабку перепишут на rust-е, а си и на этой задаче пойдёт в помойку ;)
| | |
| |
| 7.69, bOOster (ok), 21:09, 17/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
Ну а rust видимо из "святым духом" программировался из сферического вакуума простанства и времени… (facepalm)
| | |
|
|
|
| 4.56, Лис (?), 21:48, 16/08/2017 [^] [^^] [^^^] [ответить]
| –4 +/– |
Я жабу не люблю, но насколько я знаю, за счёт вирт. машины можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в определённых случаях.
Так что про скорость света это может быть несколько ошибочно.
| | |
| |
| 5.57, erthink (ok), 23:32, 16/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Я жабу не люблю, но насколько я знаю, за счёт вирт. машины
> можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в
> определённых случаях.
> Так что про скорость света это может быть несколько ошибочно.
JIT и интроспекция действительно позволяют делать некоторую оптимизацию, но вот кол-во случаев когда это получается и дает результат не так много:
1. Всяческое "совсем" позднее связывание (включая подгрузку каких-то классов на ходу), что в случае java перетекает в следующий подпункт;
2. Генерация кода самой программой;
3. Если выясняется что какой-то метод вызывается очень часто, в том числе когда часть или все параметры зафиксированы;
В C/C++ штатного JIT конечно нет, но при необходимости есть несколько вариантов (NativeJIT, LLVM, даже jithabr).
Подпункты же 1 и 3 примерно не актуальны, т.е. дают выигрыш в экосистем java, а в C/C++ и без них нормально.
Поэтому, в качестве итога = за счет упомянутых оптимизаций java может обогнать только плохой (плохо спроектированный или бездумный) код C/C++. Но в этом может быть и прелесть явы: можно упopото вить веревки из паттернов и абстракций, потом вжух и в продакшин, и оно будет работать (только медленнее C/C++).
| | |
| 5.64, лютый жабист__ (?), 17:21, 17/08/2017 [^] [^^] [^^^] [ответить]
| –3 +/– | |
>скорость света, скорость света, скорость света
Гуру из Positive Technologies видимо не знает, что в теоретической физике уже лет 100 как вполне допускается передвижение быстрее С. ;) wormhole называется. Что самое смешное, аналогия вполне в тему - движение тушки в пространстве это цепочка си - ассемблер - машинные инструкции. Си тут ДАЛЕКО не "скорость света".
А на мейнфреймах с Z/OS некоторые операции жабы исполняются сразу процом. Вполне себе такой wormhole. Си в пролёте... ;)
| | |
| |
| 6.65, Аноним (-), 17:55, 17/08/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
Тоже слышал про сжатие пространства и отрицательную энергию.
Но трицательный IQ вижу впервые, это прохая реклама для жабы.
| | |
| 6.66, лютый жабист__ (?), 18:04, 17/08/2017 [^] [^^] [^^^] [ответить]
| –3 +/– | |
Кстати, ещё очевидный тезис, не раз его озвучивал. JVM проектируют и программят зубры, навроде Шипилева. А прожки пишут простые Васи-погромисты. Половина из них чуть лучше среднего, а половина так и хуже среднего. Только не надо блабла, что сишнике все сплошь с IQ 150++
Поэтому равнять оптимизации Васи-погромиста и оптимизации Шипилёва - признак небольшого ума. Итого прога на жабе из под обычного прогера-жабиста может легко обогнать прогу на си обычного прогера-сишника. Шах и мат, братишки! Надоело очевидное рассказывать...
| | |
| |
| 7.68, erthink (ok), 20:36, 17/08/2017 [^] [^^] [^^^] [ответить]
| +3 +/– | |
Оставьте вы Леху в покое, его уже и так допекли разные грамотеи.
Знаете яву - отлично, знаете как процы работают - еще лучше.
Так продемонстрируйте сами что-нибудь, своё и не бесполезное.
Нет готового - сделайте, а не страдайте тут маразмом.
К примеру, вот возьмите и реализуйте на java это = https://github.com/leo-yuriev/t1ha
Некоторые "идиоты" (включая меня) утверждают, что это толком не возможно (будет в 4-6 раз медленнее) - покажите обратное.
Если (вдруг) не получится, то можно сделать пользу = пробросить вызовы через "Critial Natives" = https://bugs.openjdk.java.net/browse/JDK-7013347
Попробуйте сделать bench, посмотрите в v-tune и т.д.
Море возможностей...
| | |
| |
| 8.70, bOOster (ok), 21:19, 17/08/2017 [^] [^^] [^^^] [ответить] | +1 +/– | Знатно потролилил убогого Хотя это и реализуется, и почти без падения производ... текст свёрнут, показать | | |
| |
| 9.81, Аноним (-), 12:32, 18/08/2017 [^] [^^] [^^^] [ответить] | +4 +/– | Ну так предложите автору исправления Посмейтесь вместе с носителем языка и пока... текст свёрнут, показать | | |
| |
| |
| 11.84, erthink (ok), 21:50, 18/08/2017 [^] [^^] [^^^] [ответить] | +/– | Все практические задачи состоят из простых действий, каждое из которых корректне... большой текст свёрнут, показать | | |
|
|
|
|
| 7.78, Led (ok), 00:01, 18/08/2017 [^] [^^] [^^^] [ответить]
| +1 +/– |
 > JVM проектируют и программят зубры,
Зубры, мкаки, хомячки и прочие насекомые - много вас таких.
| | |
|
|
|
|
|
|
| 1.67, erthink (ok), 18:40, 17/08/2017 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– | |
RTFM.
Запросы поиска/чтения в ReOpenLDAP и libmdbx масштабируются линейно по ядрам CPU.
| | |
| |
| 2.74, Лис (?), 22:20, 17/08/2017 [^] [^^] [^^^] [ответить]
| +/– |
Спасибо за интересный проект.
Такой вопрос.
Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если да то насколько сильно?
До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по описанию в биндинге даже стандартный LMDB в сочетании с го дают большую скорость чем родной болт.
| | |
| |
| 3.76, erthink (ok), 23:12, 17/08/2017 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Спасибо за интересный проект.
> Такой вопрос.
> Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB
> https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если
> да то насколько сильно?
> До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по
> описанию в биндинге даже стандартный LMDB в сочетании с го дают
> большую скорость чем родной болт.
Да, нужно адаптировать.
Но думаю изменения будут небольшие и в основном механические.
Однако, вынужден предупредить - формат БД и API в master и devel еще не зафиксированы.
Революций в API не будет, но какие-то доработки в байндингах точно потребуются.
А формат БД и внутренности будут меняться достаточно серьезно.
Старую стабильную версию из stable/0.0 использовать не рекомендую. В свое время (для МегаФона) одним из требований была совместимость по формату БД. Поэтому многие принципиальные фичи были невозможны.
Дополню: Совместимость текстового формата dump/restore будет поддерживаться, в том числе с LMDB (если вдруг это не так - то это баг).
| | |
|
|
|
