Что там случилось с Elasticsearch?

Супер кратко:
Elastic поменял лицензию для продуктов, и они перестали быть open source. Комьюнити это не понравилось.
Теперь вышел Amazon, у которого война с Elastic, и сказал — мы форкнем, и будем дальше развивать Elasticsearch + Kibana с ALv2 лицензией.

Итого, факты:
— Elastic announced moving Apache 2.0-licensed source code to be under Server Side Public License
— Elasticsearch 7.11 будет уже под SSPL, т.е. не open-source
— Elasticsearch 7.10.x, который еще ALv2 — будет получать секьюрити апдейты до May 11th, 2022
— AWS will step up to create and maintain a ALv2-licensed fork of open source Elasticsearch and Kibana

Кто бы мог подумать 🤔

P. S. Подписывайтесь на телеграм-канал ДевОпс Инженер :)

👍НравитсяПонравилось2
В избранноеВ избранном1
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Помню, как так же поливали MongoDB...

Там всего 1 отличие от стандартной GPLv3 и, кстати говоря, не такое уж и плохое.

„If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.”

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

По сути — SSPL — это AGPLv3, но из-за формулировки, OSI считает, что оно нарушает OSD6 (No Discrimination Against Fields of Endeavor), и поэтому не есть open-source.
Но тут уже вопрос к Elastic — зачем они взяли SSPL вместо AGPL.

Упс, как всё оказалось: по сути Эластик просто нагнул Амазон, сказав что если даёте — давайте нахаляву. Амазон сказал что форкнет и будет продавать дальше.

Технически, правы оба. Но Амазон повёлся на провокацию и теперь будет за это платить разработчикам. Однако жаба задавит платить — и получат откровенно остановленный в развитии продукт даже без апдейтов безопасности.

Непонятно, что помешало дать ровно то, что они просят: исходные коды сервиса бесплатно. Но именно исходные коды, не сборку, и ипитесь сами. Абсолютное большинство предпочтут заплатить нежели собирать из исходников — уже давно прошли те времена, когда можно тупо скомпились — завсегда найдётся 100500 недокументированных граблей.

Шо то — кодинг, шо — это кодинг. Этот кодинг такая фингя, что форкал я их репу.

а всем реально так нужна полнотекстовая индексация?

Его часто используют для поиска товаров, фильтров товаров и т.п.
То есть в качестве умного индекса к рсубд

Если ресурсы недороги — почему нет? Я конечно понимаю, что полнотекстовый поиск без индекса тоже полезен, при том что достаточно редко пользуется — но когда навалят DDOSом, лучше таки иметь индекс.

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

Одна польза: когда человек ищет то, не знаю что. Например, блондинко.

Сайт типа Розетка можно сделать полностью на Эластике

Ага, особенно работу с корзиной и биллинг.

И это тоже можно. Правда из-за отсутствия транзакций придется морочится с двухфазным комитом.

Хотел бы посмотреть на этот UI с учетом того, что чтение из индекса eventually consistent и недетерминировано всегда для сценариев, где юзер ожидает увидеть изменение сразу после своего действия.

Это консистенси существует только в идеальном мире. В реальной платежной системе транзакция должна быть закомичена в нескольких системах. В процессинге карты, списание на складских системах учёта, списание в внутренней базе, экспорт данных в вархаус и тд. Все это разнородные базы и ролбеки в них делаются натурально вручную отдельным кодом. Поэтому если заменят RDBMS эластиком для OLTP, да не оч хорошо. Но общей погоды особо не сделают. Ибо транзакцию провести это не строчечку в одну базу записать.

Какие ещё базы и транзакции? Я за чтение говорю простой записи инкремента в корзине. Elastic поисковый индекс — он не годен вообще для любых user сценариев взаимодействия с сайтом, где он что-то меняет и должен увидеть сразу результат.

Почему он не увидет сразу результат ? Такие системы пишутся на базе LSM деревьев. Это означает что часть индекса в памяти, часть индекса на диске. Что не смержено на диск, хранится в оплоге. Если добавите документ, его сразу увидите в индексе.

ПС Вашу корзину вообще можно в кеше хранить сервера в каком нибудь редисе, пока юзер не нажал кнопку купить это натурально муссор для базы.

Почему он не увидет сразу результат ? Такие системы пишутся на базе LSM деревьев. Это означает что часть индекса в памяти, часть индекса на диске. Что не смержено на диск, хранится в оплоге. Если добавите документ, его сразу увидите в индексе.

Indexed and updated documents are not immediately available for search in Elasticsearch. Each index has a refresh interval, which default to 1s, periodically making indexed or updated documents available for search. The reason for this is that this is an expensive operation, which is best performed periodically on a set of documents rather than individually for each document. As you seem to be running your commends in quick sequence, the refresh has may not had time to happen by the time you search for the document, which is why you do not see any results.

You can explicitly force a refresh on an index 56, but beware that this will affect performance negatively if performed often.

discuss.elastic.co/...​at-ive-just-indexed/48777

Сам же результат индексации вообще появиться хз когда — происходит асинхронно. Все описанные варианты получения strong consistency — костыли, на практике никто так не юзает поисковые индексы что б сделать на elastic интернет магазин(его задача вообще локальна — каталог/поиск по сайту).

Читай не форумы пятилетней давности.
А документацию как оно сейчас работает

www.elastic.co/...​/current/docs-index_.html

refresh
(Optional, enum) If true, Elasticsearch refreshes the affected shards to make this operation visible to search, if wait_for then wait for a refresh to make this operation visible to search, if false do nothing with refreshes. Valid values: true, false, wait_for. Default: false.

Читай не форумы пятилетней давности.
А документацию как оно сейчас работает

Во-первых за 5 лет это поведение и апи не поменялось, во-вторых там чат с девелоперами elastic, что объясняют поведение как индексирует lucene, в-третьих та опция, что предлагается в той же официальной доке грубо говоря не рекомендуется
www.elastic.co/...​/master/docs-refresh.html

Empty string or true
Refresh the relevant primary and replica shards (not the whole index) immediately after the operation occurs, so that the updated document appears in search results immediately. This should ONLY be done after careful thought and verification that it does not lead to poor performance, both from an indexing and a search standpoint.

true creates less efficient indexes constructs (tiny segments) that must later be merged into more efficient index constructs (larger segments). Meaning that the cost of true is paid at index time to create the tiny segment, at search time to search the tiny segment, and at merge time to make the larger segments.

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

Эволюция мнения от

он не годен вообще для любых user сценариев взаимодействия с сайтом, где он что-то меняет и должен увидеть сразу результат.

До

грубо говоря не рекомендуется

Кстате говоря я плохо знаком с Эластиком. Как обычно тыкал в кибане настраивал логи.

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

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

Кстате говоря я плохо знаком с Эластиком.

уже не новость совсем.

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

Можешь попробовать контрибьютнуть им в доку, там эти выводы пропущены как раз, видать в elastic не разобрались до конца.

Можешь попробовать контрибьютнуть

Зачем контрибутить конкурентов ?

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

Всего-лишь. Такой вот пустячок :)

Именно пустячок. Если есть возможность сделать синхронный и асинхронный апи, то впихнут конечно асинхронный. Чтобы вокруг меряли красивые бенчмарки. А кому нужно синхронный вызов, уже дотюнит под себя и передаст флажок рефреш тру. Так работают маркетологи. Но с технической точки зрения, повторюсь, получить добавленый док сразу в поиске — никаких проблем нет.

есть и дело не в комите на реплики и это чёрным по белому написано в документации, на которую ты ссылаешься.

По твоей же ссылке

Elasticsearch automatically refreshes shards that have changed every index.refresh_interval which defaults to one second.

речь о апдейте части индекса, а не реплики. Ты даже не вкуриваешь, что такое шарда?

Вот описание проблемной сторони

true creates less efficient indexes constructs (tiny segments) that must later be merged into more efficient index constructs (larger segments). Meaning that the cost of true is paid at index time to create the tiny segment, at search time to search the tiny segment, and at merge time to make the larger segments.

никакого референса на проблематику связанную с репликацей тут нет. она существует только в твоей больной фантазии.

речь о апдейте части индекса, а не реплики. Ты даже не вкуриваешь, что такое шарда?

Скорей ты не вкуриваешь кап теорему

true creates less efficient indexes constructs (tiny segments) that must later be merged into more efficient index constructs (larger segments). Meaning that the cost of true is paid at index time to create the tiny segment, at search time to search the tiny segment, and at merge time to make the larger segments.

Открыл для себя что такое M в аббревиатуре LSM, о котором тебе говорили первым постом ? Молодец.

Скорей ты не вкуриваешь кап теорему

Cap тут не к месту вообще. Elastic точно такое же поведение индексации имеет в режиме single node/shard конфигурации без реплик.пробуй ещё.

dou.ua/...​rums/topic/32576/#2045915

Дальше не имею лишнего времени вести дискуссию. Одно дело когда понимаешь логически как оно работает, а другое когда аникейщик пытается склеить как оно работает по обрывкам документации и не получает полной картины. Что происходит внутри для него blackbox.

Ну и чтоб два раза не вставать

The Lucene index is split into smaller chunks called segments. Each segment is its own index. Lucene searches all of them in sequence.

A new segment is created when a new writer is opened and when a writer commits or is closed.

The advantages of using this system are that you never have to modify the files of a segment once it is created. When you are adding new documents in your index, they are added to the next segment. Previous segments are never modified

А теперь подумай, что мешает документу сразу быть в поиске, если на него сразу создан индекс ?
M означает Merge. Все эти сегменты сливаются постепенно в один большой индекс на диске. И де-факто, если у тебя один сервак, док сразу виден в индексе.
Поиск ищет док в сегментах памяти и потом в сегментах на диске. Результаты объединяются.
И эту идилию нарушает только распределённая система в которой нужно не просто в памяти индекс строить, а пропагейтить изменения на другие ноды.

Я тебе уже сказал, что поисковые lucene-based движки по дефолту не дают сразу в поиске результаты в режиме single-node. Это факт — пока вся твоя теория вокруг cap разбивается о эту примечательную особенность.

Ну и чтоб два раза не вставать

The Lucene index is split into smaller chunks called segments. Each segment is its own index. Lucene searches all of them in sequence.

A new segment is created when a new writer is opened and when a writer commits or is closed.

The advantages of using this system are that you never have to modify the files of a segment once it is created. When you are adding new documents in your index, they are added to the next segment. Previous segments are never modified

что бы понимать как дальше отвечать стало интересно откуда копипаста. с сожалением открыл для себя ссылка ведет на stackoverflow с вопросом What are segments in Lucene?
stackoverflow.com/...​at-are-segments-in-lucene
:)
полагаю ты прочитал мой абзац про мердж сегментов и тут начал гуглить, что такое сегмент в lucene, что бы опять вылить сюда какой-то поток несвязанных мыслей.

Я тебе помогу вникнуть в азы. Вот неплохой блог пост, где на пальцах обьясняют как работает lucene и почему данные в поиске не попадают сразу
alibaba-cloud.medium.com/...​sic-concepts-5ff5d8b90a53

Segment
An index is composed of one or more sub-indexes. A sub-index is called a segment. The conceptual design of Segments in Lucene is similar to LSM but there are some differences. They inherit the data writing advantages of LSM but only provide near real-time and not real-time queries.
When Lucene writes data it first writes to an in-memory buffer (similar to MemTable in LSM, but not readable). When the data in the Buffer reaches a certain amount, it will be flushed to become a Segment. Every segment has its own independent index and are independently searchable, but the data can never be changed. This scheme prevents random writes. Data is written as Batch or as an Append and achieves a high throughput. The documents written in the Segment cannot be modified, but they can be deleted. The deletion method does not change the file in its original, internal location, but the DocID of the document to be deleted is saved by another file to ensure that the data file cannot be modified. Index queries need to query multiple Segments and merge the results, as well as handling deleted documents. In order to optimize queries, Lucene has a policy to merge multiple segments and in this regard is similar to LSM’s Merge of SSTable.
Before segments are flushed or committed, data is stored in memory and is unsearchable.This is another reason why Lucene is said to provide near-real time and not real-time queries. After reading the code, I found that it’s not that it can’t implement data writing that’s searchable, just that it’s complicated to implement. The reason for this is the searching of data in Lucene relies on the index setup (for example, an inverted index relies on Term Dictionary), and the data index in Lucene is set up during a Segment flush and not in real-time. The purpose of this is to set up the most efficient index. Naturally, it can introduce another index mechanism that sets up the index in real time as it is written, but the implementation of such a mechanism would differ from the current index in the segment, needing the introduction of an extra index at write time and an extra query mechanism, involving some degree of complexity.

Опять же с твоего текста.

Before segments are flushed or committed, data is stored in memory and is unsearchable. This is another reason why Lucene is said to provide near-real time and not real-time queries. After reading the code, I found that it’s not that it can’t implement data writing that’s searchable, just that it’s complicated to implement. The reason for this is the searching of data in Lucene relies on the index setup (for example, an inverted index relies on Term Dictionary), and the data index in Lucene is set up during a Segment flush and not in real-time.

И о чудо. В Эластике появился флаг Refresh = True, Refresh=WaitFor,
который делает документ в реалтайме видимым в поиске.

А теперь опять переосмысли свой первый пост, с которого начался холивор.

он не годен вообще для любых user сценариев взаимодействия с сайтом, где он что-то меняет и должен увидеть сразу результат.

Выше уже это обсудили — юзать рефреш не рекомендует сам вендор, так как это влечёт неэффективное обновление индекса и создаёт ненужную экстра-нагрузку на кластер, иначе бы это было поведение по умолчанию без надобности выставлять флаги. Более того сам продукт не позиционируется как real-time search engine.
те кто юзают его для решения продуктивных задач и знают как он работает ‘под капотом’ этого не делают. В том числе не делают на нем риалтайм сценарии для нагруженных онлайн-магазинов.
Ты конечно можешь юзать эластик для риалтайм систем все равно, если оно тебе действительно надо. :)

Почему он не увидет сразу результат ? Такие системы пишутся на базе LSM деревьев.

LSM это всего лишь адаптация того, что иначе бы делалось на B-tree, для скоростной поточной записи. Все операции он немедленно пишет в текущий журнал.
Если вы про текущий лог в памяти, он не обязан использоваться как кэш — и он не предназначен использоваться как кэш (когда текущий журнал переполнится, сбрасывается и представление в памяти).
Кэш над таким индексом делается отдельно. Хотя если в ES применили его в качестве кэша — я не удивляюсь некоторым, хм, особенностям работы...

Ничего не понял. Ещё раз, на пальцах.
Вы отправили 1000 файлов на индексацию. Парсеры в рам распарсили уложили в инвертированный индекс. В оплог записали для дюрабилити. В какой-то момент рам должен быть сброшен на диск. Страницы индекса с рам мержатся с страницами на диске.
Все возможные проблемы могут быть связаны с тем, чтобы увидеть данные сразу по всем нодам, описаны кап теоремой. Именно по этому скорей всего дефолт для рефреш стоит false. Но если у вас один сервер или можете чуть подождать можно смело конфигурить в тру и видеть документ сразу в поиске по всем нодам.

йой реклама на срачах (Кто бы мог подумать) падпісивайтєсь :)))

Попадалась недавно статья на глаза.
m.habr.com/ru/post/437116

З вашої новини складається враження, що «фу, які погані Еластік, хочуть закрити код Еластіксерча. А от AWS молодці, не дадуть опенсорсу загнутися 💪».

Хоча все якраз навпаки.

Еластік закриває ліцензію, бо Амазон роками продавав платні ліцензії на Amazon Elasticsearch Service — і при цьому нічо не платив Еластіку.

Позиція Еластіка:
www.elastic.co/...​og/why-license-change-AWS

Як на мене, опенсорс чи ні — якщо AWS заробляють на результатах чужої праці, то вони мають платити якусь частку тим, хто займається розробкою.

Потому что именно Амазон и вбросил на вентилятор.

Якщо ліцензія дозволяє безкоштовне комерційне використання опен сорс проекту, то амазон нічого не має платити. Якщо опен сорс хоче грошей, треба або відповідна ліцензія, або переходити від опен сорсу.

OpenSource != Freeware.

Есть ещё украинские проекты FTS.
Black Hole
github.com/Bazist/BH
Индексация около 50 мб сек.
Сжатие индекса (не текста) около 97%
Поиск микро/милли секунды.
Код отлажен на 9тб базе на посредственной виртуалке.

github.com/...​0fe80863a/HArray/makefile

Решил я посмотреть твою поделку — makefile нерабочий

artem@Dell-New:~/src/ht/HArray/HArray$ make
makefile:6: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

Я запускаю через Visual Studio.
Ctrl + F5. Все что нужно чтобы запустить проект и увидеть прогон всех бенчмарков
Мейкфайл мне когда-то прислали, не проверить не починить нет возможности в ближайшее время. Сорян.

Все что нужно чтобы запустить проект и увидеть прогон всех бенчмарков

Запустить не выдет. Падает с NRE. Но разбираться почему у меня желания уже нет, особенно после того, как увидел параметр метода Func action — привет возможным саппортерам)))
А потом глаз закровил на if (errorHandler != null) { errorHander();}
Гуанокод вычисти, а потом занимайся саморекламой))

Ничего не понял. Пальцы попали мимо Cntrl+F5 ?
В HArray проекте нет никаких

errorHandler

.
Там просто скачивается и запукается проект в один клик.

Все, я понял. Ты про BH а не про.

artem@Dell-New:~/src/ht/HArray/HArray$ make

про который писал Артем.

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

Его я не рекламирую, поскольку с точки зрения запуска в новой инфраструктуре
он требует моей помощи, поскольку с документацией пока не сложилось.

Что это как не реклама?))

Есть ещё украинские проекты FTS.
Black Hole
github.com/Bazist/BH

Это реклама, но реклама бета версии.
Может кому будет интересно кастомизировать под свои задачи или помочь улучшить проект.
Самая сложная часть в нем уже написана и отлажена.

Мейкфайл мне когда-то прислали, не проверить не починить нет возможности в ближайшее время. Сорян.

Ты не можешь виртуалку убунту установить и проверить, или арендовать линукс машину на AWS за 2 доллара в месяц?

Конечно могу. Но портирование под Линукс не в моем приоритете. Моя рабочая ось винда, она мне не создаёт проблем концентрироваться на алгоритмах и их реализациях. Если кому проект будет интересен, то нормальная практика сделать свой порт на нужную платформу. На нужный язык. Я не являюсь экспертом по разным экосистемам. Если мне помогают что-то портировать — я делаю. Если нет — откладываю на потом.

Встановіть Docker і запустіть як звичайний контейнер. Це 5-7 хвилин вашого часу.
Все безкоштовно і працює безвідмовно.

Я бы помог, если бы было:

1) Адекватная документация алгоритма
2) Адекватный сапорт от разработчика

Пока что ни того ни другого не наблюдается.

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

Вы почему-то все ждёте код и документацию уровня Эластика от одного человека. Но на эластик потрачено сотни миллионы баксов, а на мой проект — нет.
К тому же каждый умник который работает с мейк файлами, обязательно расскажет что он херово написан. Мне на этот файл нужно потратить 2 часа, я им не пользуюсь. Умнику — 5 минут. Но умник будет рассказывать, что мне нужно качать и ставить убунту.
Нет, помощь таких умников мне не нужна.
Мне нужна помощь адекватных людей, которым не влом потратить 5 минут своего времени и сделать нормальный мейк файл, если им чтобы его сделать не нужно что-то устанавливать или читать документацию.

Вы почему-то все ждёте код и документацию уровня Эластика от одного человека. Но на эластик потрачено сотни миллионы баксов, а на мой проект — нет.

Никто не ждет документацию уровня эластика. Нужно описание алгоритма и какое-то базовое формальное доказательство его корректности. Вот пример:

doc.dpdk.org/...​/prog_guide/ring_lib.html

На это не нужно сто миллионов долларов. Нужен человек, который понимает что там под капотом (надеюсь, ты понимаешь), способный писать на понятном языке и несколько часов времени.

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

К тому же каждый умник который работает с мейк файлами, обязательно расскажет что он херово написан. Мне на этот файл нужно потратить 2 часа, я им не пользуюсь. Умнику — 5 минут. Но умник будет рассказывать, что мне нужно качать и ставить убунту.
Нет, помощь таких умников мне не нужна.
Мне нужна помощь адекватных людей, которым не влом потратить 5 минут своего времени и сделать нормальный мейк файл, если им чтобы его сделать не нужно что-то устанавливать или читать документацию.

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

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

Ок, месседж понят. Постараюсь исправить.
Правда этот проект пока на паузе, но в другом проекте (днипра) документации будет уделено много времени. Также думаю о своем ютуб канале, с маркером возле доски. Такой формат мне кажется перспективным, чтобы кратко и наглядно доносить основные мысли до комьюнити.

Примерно в той же ситуации нахожусь. Тебя напрягают, бро. Скажи себе — некуда спешить. Если бы кто-то хотел ускорить процесс — он выдал бы тебе целый дипломат овеществленного времени — на который ты смог бы нанять документатора, например... И т.д.. Люди почему-то считают, что один человек способен превысить скорость света. Распределенные вычисления человеческими мозгами им явно неведомы.
Вот сколько есть у тебя времени — ресурсов — денег — вот ровно столько, в нормальном режиме его и должно проходить между строчками неровного но гениального кода.

Тут другого пути нет. Нужно учится доносить мысль (и мне и тебе). Если есть что сказать о своем проекте и его основных идеях.

Зачем? Кому надо тот посмотрит на то, что делает твой код и сделает копию делания. Например, я снимаю видео о том, что делает мой код. И не стану возражать, если кто-то использует схему вроде:


outer_html - 
screen(s) - 
inner_html(s) - 
selected_activity(ies) - 
processing_result(s)
В своей собственной разработке. Даже приветствовать буду это.
А вот что не буду приветствовать, так это указание как мне писать мой код, чтобы это было понятно другим.
Смотрите на результаты, на статистику профайлера и флаг в руки.

Пофиксил.
Сборка make
Запуск .\HArray

Будемо пробувати інші продукти, на Rust вже є MeiliSearch та Sonic

Про альтернативи Elasticsearch вже думав раніше, ще до новин про зміну ліцензії

Будете пробувати... search engine замість еластіка і MPL замість SSPL? )

Подписаться на комментарии