diff-компрессия массивов вхождений, "вынесение за скобки" идентификатора формы слова и кодирование по статическим таблицам по Хаффману для высокочастотных слов (и, в, пунктуация) - применяется буквально во всех машинках.
Обычно всё-таки И индексный файл (по ключу адресовать blob), И последовательное чтение этих упорядоченых blob-ов c "пересечением слиянием".
Использую ЧатГопоту и ДипСик. Фактически, как раньше Goodie: вместо того, чтобы давать пяток запросов, пишу один промпт.
В плане написания кода на c++ обе модели в моих задачах - а задачи у меня в основном алгоритмические - очень слабы. Это даже не "джуниор", а "прекрасно освоивший синтаксис языка выпускник курсов, не имеющий базового образования".
Итеративный тюнинг запросов редко улучшает порождённый код, прямые указания на логические ошибки исправляются заплатками, замечания о неэффективности использования динамических массивов (std::vector) при написании критических по скорости фрагментов принимаются безоговорочно, и вместо вектора подставляются непосредственные аллокации.
Справедливости ради замечу, что код для перекладывания json-чиков обе системы пишут вполне приемлемо: js-интерфейс к поиску по файлам на локальной машине заработал сразу с единственной проблемой - миганием при обновлении. Ручное удаление лишнего .show() проблемы решило, код вполне приемлемый, пошёл в прод без дальнейших ручных доработок.
При использовании в режиме умного справочника регулярно натыкаюсь на галлюцинирование. Причём deepseek ещё и готов подпереть свои галлюцинации ссылками. Которые ведут в никуда. И только после прямого "обвинения" во вранье признаётся, что "додумал", информации такой в прямом доступе нет, однако всё должно обстоять именно так. Это я его пытал про устройство ядра 4G LTE.
Средняя дочка хочет в профессию, но очень переживает, не вытеснит ли нас ИИ. Объяснил ей, что "чем удобряли, то и выросло", показал примеры кода от ИИ и "как надо" - вроде, успокоилась.
Я, отработав в компании МойОфис 9 лет и покинув её в январе, добавил бы важнейший, на мой взгляд, раздел в статью.
Мотивация - хорошо, однако прежде всего не должно быть мощных демотиваторов. В частности, высокопоставленный дурак или воинствующая некомпетентность, наделённая реальной властью - наверное, самый мощный демотиватор после прямого обмана сотрудников.
К чести компании замечу, что она не только не была за 9 лет замечена в "кидалове", но даже несколько шокировала меня выплатой заметного размера премии через несколько месяцев после моего ухода!
(здесь было много текста с упоминанием имён наиболее сильных демотиваторов, но решил не публиковать)
Искренне надеюсь, что автор статьи - достойный руководитель проекта. Хочется верить, что "всё было не зря".
В 1986 Полторак стал нам физико-химические основы неорганической химии, и в разделе "Термометрия" сказал дословно следующее:
Измерение температуры построено на двух предположениях, первое из которых произвольно, а второе заведомо ошибочно. Первое - выбор реперных точек. Второе - утверждение, что шкала между ними линейна.
В реальности размер ключа не фиксированный, но, казалось бы, для хэш-таблицы это влияет только на её физический размер, и ограничений там быть не должно.
Типичный размер словаря ключей немного поработавшей перимущественно русскояычной полнотекстовой машины - за миллион (~60,000 русской общей лексики из активного запаса, два по столько орфографических ошибок, формально годящихся в русские слова, остальное - числа и иероглифы вроде rs232).
Тут под соседей заметкой меня практически спросили, зачем нужен другой полнотекстовый поиск, если есть Apache Lucene. Не дословно, конечно, но это подразумевалось.
Да, вы совершенно правы: если нужна оценка размера некоторой массивной и кучерявой структуры данных, то GetBufLen проделывает весь путь Serialize, а время на её исполнение пропорционально времени Serialize с коэффициентом, равным отношению времени операции суммирования ко времени операции записи в конкретный коллектор.
С другой стороны, такая оценка нужна ровно в двух случаях: либо если вы собираетесь сделать дамп в памяти и хотите понять, сколько её надо резервировать, либо если вам надо строить внутренние таблицы релокации внутри такого дампа.
Эта была сделана в своё время для построения дампов словарных данных, по которым можно эффективно искать, не десериализуя.Где активно и используется (libmorph).
Так всё-таки к разработке каких известных полнотекстовых поисковых движков вы имели отношение? Или хотя бы к эксплуатации?
---
Пардон, заглянул - там Apache Lucerne, разработка двадцатилетней давности, довольно громоздкая и с низким качеством поиска (отношение правильно найденных к общему количеству найденных), на сегодня - прошлый век.
Видимо, проделана большая работа над тем, чтобы оно таки шевелилось.
1 и 2 справедливы для обоих подходов - и для упомянутой вами хэш-таблицы,и для сериализованного базисного дерева.
Однако у хэш-таблиц есть очевидный недостаток: построить по ней итератор, перебирающий ключи в порядке возрастания (убывания) сложно и дорого. А в прикладных задачах полнотекстового поиска этот итератор важен и нужен.
Хэш-таблица, демонстрирующая o(1), будет к тому же, вероятно, очень разреженной, а значит, "жирной" по размеру.
А про скорость поговорим в следующей заметке, добавим хэш-таблицу в сравнение производительности.
Нет. Это не так. Если передать по ссылке, то, например, для сериализации в память надо будет писать специальную обёртку, а не использовать простой char* - указатель, а вместо возврата nullptr в случае ошибки придётся бросаться exception'ами.
Это нормально.
diff-компрессия массивов вхождений, "вынесение за скобки" идентификатора формы слова и кодирование по статическим таблицам по Хаффману для высокочастотных слов (и, в, пунктуация) - применяется буквально во всех машинках.
Обычно всё-таки И индексный файл (по ключу адресовать blob), И последовательное чтение этих упорядоченых blob-ов c "пересечением слиянием".
Использую ЧатГопоту и ДипСик. Фактически, как раньше Goodie: вместо того, чтобы давать пяток запросов, пишу один промпт.
В плане написания кода на c++ обе модели в моих задачах - а задачи у меня в основном алгоритмические - очень слабы. Это даже не "джуниор", а "прекрасно освоивший синтаксис языка выпускник курсов, не имеющий базового образования".
Итеративный тюнинг запросов редко улучшает порождённый код, прямые указания на логические ошибки исправляются заплатками, замечания о неэффективности использования динамических массивов (std::vector) при написании критических по скорости фрагментов принимаются безоговорочно, и вместо вектора подставляются непосредственные аллокации.
Справедливости ради замечу, что код для перекладывания json-чиков обе системы пишут вполне приемлемо: js-интерфейс к поиску по файлам на локальной машине заработал сразу с единственной проблемой - миганием при обновлении. Ручное удаление лишнего .show() проблемы решило, код вполне приемлемый, пошёл в прод без дальнейших ручных доработок.
При использовании в режиме умного справочника регулярно натыкаюсь на галлюцинирование. Причём deepseek ещё и готов подпереть свои галлюцинации ссылками. Которые ведут в никуда. И только после прямого "обвинения" во вранье признаётся, что "додумал", информации такой в прямом доступе нет, однако всё должно обстоять именно так. Это я его пытал про устройство ядра 4G LTE.
Средняя дочка хочет в профессию, но очень переживает, не вытеснит ли нас ИИ. Объяснил ей, что "чем удобряли, то и выросло", показал примеры кода от ИИ и "как надо" - вроде, успокоилась.
Видимо, таки давно: пят лет назад либерда торчала от инфы, что у 70% нет заграна.
На картинке некий усталый скуф.
Индеец (Олег, прости, но тебя так многие зовут за глаза) не такой - он бегает, по горам ходит, и подтянутый.
Вообще говоря, до сих пор не была случая отвала "нужного куска Интернет".
Хотя сама сеть, да, иногда падает.
Ну, как бы, уж насколько ранжирование слабое у Elastic, но здесь даже обратная частота термина (его избирательность) не будет учитываться!
Я, отработав в компании МойОфис 9 лет и покинув её в январе, добавил бы важнейший, на мой взгляд, раздел в статью.
Мотивация - хорошо, однако прежде всего не должно быть мощных демотиваторов. В частности, высокопоставленный дурак или воинствующая некомпетентность, наделённая реальной властью - наверное, самый мощный демотиватор после прямого обмана сотрудников.
К чести компании замечу, что она не только не была за 9 лет замечена в "кидалове", но даже несколько шокировала меня выплатой заметного размера премии через несколько месяцев после моего ухода!
(здесь было много текста с упоминанием имён наиболее сильных демотиваторов, но решил не публиковать)
Искренне надеюсь, что автор статьи - достойный руководитель проекта. Хочется верить, что "всё было не зря".
В 1986 Полторак стал нам физико-химические основы неорганической химии, и в разделе "Термометрия" сказал дословно следующее:
Измерение температуры построено на двух предположениях, первое из которых произвольно, а второе заведомо ошибочно. Первое - выбор реперных точек. Второе - утверждение, что шкала между ними линейна.
Да, разумно.
В реальности размер ключа не фиксированный, но, казалось бы, для хэш-таблицы это влияет только на её физический размер, и ограничений там быть не должно.
Типичный размер словаря ключей немного поработавшей перимущественно русскояычной полнотекстовой машины - за миллион (~60,000 русской общей лексики из активного запаса, два по столько орфографических ошибок, формально годящихся в русские слова, остальное - числа и иероглифы вроде rs232).
Да ладно...
Тут под соседей заметкой меня практически спросили, зачем нужен другой полнотекстовый поиск, если есть Apache Lucene. Не дословно, конечно, но это подразумевалось.
Да, вы совершенно правы: если нужна оценка размера некоторой массивной и кучерявой структуры данных, то GetBufLen проделывает весь путь Serialize, а время на её исполнение пропорционально времени Serialize с коэффициентом, равным отношению времени операции суммирования ко времени операции записи в конкретный коллектор.
С другой стороны, такая оценка нужна ровно в двух случаях: либо если вы собираетесь сделать дамп в памяти и хотите понять, сколько её надо резервировать, либо если вам надо строить внутренние таблицы релокации внутри такого дампа.
Размер ключа у полнотекстовой поисковой машины невелик: от 3-4 до 20-25 байт. В зависимости от того, словарная это лексема или неизвестная.
А как вы хотите на hash-таблице сделать итератор по ключам? Например, для реализации поиска с усечением - сло*?
Выложил для того, чтобы было на что ссылаться при выкладке библиотеки полнотекстового поиска.
Эта была сделана в своё время для построения дампов словарных данных, по которым можно эффективно искать, не десериализуя.Где активно и используется (libmorph).
Непременно прочту.
Так всё-таки к разработке каких известных полнотекстовых поисковых движков вы имели отношение? Или хотя бы к эксплуатации?
---
Пардон, заглянул - там Apache Lucerne, разработка двадцатилетней давности, довольно громоздкая и с низким качеством поиска (отношение правильно найденных к общему количеству найденных), на сегодня - прошлый век.
Видимо, проделана большая работа над тем, чтобы оно таки шевелилось.
Терешке, думаю, тяжело пришлось обосновывать TCO.
Ну так какой из больших или хотя бы малых полнотекстовых движков вы сделали? Или хотя бы поучаствовали, хотя бы в качестве сеньора?
Из больших - Апорт!, Рамблер от 2000 года и дальше, украинскую Мету.
Эти три спроектировал, в значительной мере написал, последние два потом развивал и эксплуатировал.
И несколько поменьше.
А вы?
"Любимые БД" сильно просаживает производительность поисковых движков.
Требуют много памяти и медленно работают.
А я веду именно туда.
1 и 2 справедливы для обоих подходов - и для упомянутой вами хэш-таблицы,и для сериализованного базисного дерева.
Однако у хэш-таблиц есть очевидный недостаток: построить по ней итератор, перебирающий ключи в порядке возрастания (убывания) сложно и дорого. А в прикладных задачах полнотекстового поиска этот итератор важен и нужен.
Хэш-таблица, демонстрирующая o(1), будет к тому же, вероятно, очень разреженной, а значит, "жирной" по размеру.
А про скорость поговорим в следующей заметке, добавим хэш-таблицу в сравнение производительности.
Нет. Это не так. Если передать по ссылке, то, например, для сериализации в память надо будет писать специальную обёртку, а не использовать простой char* - указатель, а вместо возврата nullptr в случае ошибки придётся бросаться exception'ами.