Все-таки пока 50, и 20-30 минут - это для 50. Но ради заголовка я попробовал и 100, просто продублировав товары с разными Id - работает.
Что касается LuceneNet, то определенно стоит изучить возможности. Но я люблю работать с алгоритмами больше, чем с конфигурациями, а тут такая возможность появилась.
Поиск для конечных пользователей, когда до него дойдет очередь, будем строить на сторонних библиотеках, скорее всего. А требования (или пожелания) к поиску для администраторов как раз лучше закрываются самописным алгоритмом.
Первоначальное заполнение занимает около 20-30 минут.
Что касается готовых движков, то те, с которыми я работал раньше, не умели искать по подстроке, то есть, были не способны найти "65U790KB" по запросу "65U790K", а это в нашем случае важно. По сути, такое поведение понятно, они создавались для поиска по тексту на естественном языке. Возможно, сейчас кто-то уже так может, но я положился на свой прошлый опыт.
Второй вариант - использовать готовый движок, но с индексом не по словам, а по триграммам. И сначала у нас был именно такой подход, но в какой-то момент перестала устраивать скорость работы.
Есть еще два аргумента против готового:
Свой поиск получился довольно простым по устройству, и его мы полностью контролируем, а не ограничены настройками готового движка. С другой стороны, мы ограничены своими возможностями, и, например, морфологии у нас никогда не будет.
Мы стараемся минимизировать количество инфраструктурных зависимостей. Сейчас такая зависимость только одна - SQL Server. В общем, такой вот keep it simple.
Я даже не знаю, сколько пустых, но давайте попробуем посчитать потенциальную экономию.
public class List<T> : IList<T>, IList, IReadOnlyList<T>
{
private const int DefaultCapacity = 4;
internal T[] _items; // Do not rename (binary serialization)
internal int _size; // Do not rename (binary serialization)
private int _version; // Do not rename (binary serialization)
private static readonly T[] s_emptyArray = new T[0];
........
}
Это фрагмент исходного кода .NET 5
Для хранения пустого списка на 64-битной системе потребуется 8 + 4 + 4 = 16 байт. Плюс хранение ссылки на этот список потребует 8 байт, итого 24 байта без учета выравнивания. Потребление памяти с выравниванием я сходу не посчитаю, к сожалению, поэтому оставим так.
Всего у нас 343 000 списков, это дает 8 232 000 байт потенциальной экономии для случаев, когда индекс создали, а использовать не стали.
Думаю, в нашем случае, когда индекс создается в одном экземпляре, экономией 8 мегабайт памяти можно пренебречь ради упрощения кода. С другой стороны, если бы речь шла про переиспользуемую библиотеку, учесть это обязательно нужно.
Возможно, я найду время и оформлю эту идею в виде nuget - пакета, и тогда сделаю ленивую инициализацию.
Нам нужно искать слова с опечатками и просто похожие варианты, и поиск не ограничивается только словами русского / английского языка. Например, на запрос "65U710KB" нужно предложить вариант "65U790KB", если ничего лучшего не было найдено.
Это поиск не для пользователей интернет-магазина, а для администраторов, и такой поиск упрощает их работу.
Простите, не так вас понял. Да, это можно. Конкретно в нашей ситуации сначала проще докупать память на одном сервере, чем делать масштабирование. До 256 ГБ можно докупить, дальше упираемся в ограничения используемого железа.
Если же делать из этого публичное решение, то конечно, масштабирование необходимо.
Все просто, горизонтальное масштабирование позволит хранить больше данных, но не позволит MS SQL Server быстрее искать по полнотекстовому индексу. Вызов функции Containstable на таком объеме данных занимает 98% времени обработки запроса, то есть, по сути те 2-5 секунд, о которых я писал вначале, и принципиально его не ускорить. Вместо этого мы сделали метод, который работает за 10 миллисекунд, эта часть ускорилась в 200-500 раз.
А что до ограничений памяти сервера, то аренда сервера с 64 гигабайтами стоит 50 евро в месяц. И ещё запас для роста в 2 раза остался.
Я не знаю, при помощи какого инструмента можно добиться такого результата "из коробки".
Поискал в Гугле, нашел упоминание 18000, 20000 как максимальных оборотов в минуту, и 6150 как оборотов в минуту, на которых достигается максимальная мощность, но это не конкретно plaid.
Спрашиваю потому что 60000 rpm - это очень много, это 1000 оборотов в секунду. По грубым прикидкам в уме при такой скорости вращения большого мотора напряжения в материале выше предела текучести стали. Конечно, есть и другие материалы, но все же непонятно, ради чего нужно преодолевать столько сложностей.
Как писали представители проекта Event Horizon Telescope, разрешения, достигнутого в проекте (25 микродуговых секунд), достаточно, чтобы читать газету в Нью-Йорке, находясь в уличном кафе в Париже.
Если понимать 25 микродуговых секунд как 25 микросекунд дуги, линейное разрешение на расстоянии 5800 км составит 42 миллиметра. При стандартной ширине полосы газеты, равной 300 миллиметров, это 7 пикселей в ширину. В общем, вот.
Попробую дать определение определенному поведению для C++20: это поведение, закрепленное в стандарте International Standard ISO/IEC 14882:2020(E) – Programming Language C++.
То, что поведение не меняется со временем, к определенному поведению отношения не имеет, если стандарт не предусматривает однозначного поведения для такой ситуации. Даже если какой-то код ведет себя одинаково с любым известным компилятором и любой известной средой выполнения, но стандарт не предусматривает однозначного поведения в такой ситуации - это все равно неопределенное поведение.
Я не спорю с тезисом про разные проекции, но пример с Африкой и Евразией не понял. На контурных картах, насколько я помню, Евразия была больше Африки. В реальности Евразия больше Африки.
Возможно, вы имели в виду пример с Россией (или СССР) и Африкой. В этом случае, если по памяти, то на карте они примерно одинаковой площади, хотя в реальности Африка значительно больше.
Я чуть мозг не сломал, пытаясь понять, что не так с вашим комментарием.
В таком случае деплатформить должны юрлицо, а не хостинг. И госорганы, а не частная компания.
Очень хочется иметь такое меню на десктопе во-первых, и возможность настраивать доступные пункты на мобильном во-вторых.
Лично мне нужны только copy и web search, но web search спрятан за тремя точками.
А на десктопе пока расширением Selection Search пользуюсь, но оно неидеально работает.
Все-таки пока 50, и 20-30 минут - это для 50. Но ради заголовка я попробовал и 100, просто продублировав товары с разными Id - работает.
Что касается LuceneNet, то определенно стоит изучить возможности. Но я люблю работать с алгоритмами больше, чем с конфигурациями, а тут такая возможность появилась.
Поиск для конечных пользователей, когда до него дойдет очередь, будем строить на сторонних библиотеках, скорее всего. А требования (или пожелания) к поиску для администраторов как раз лучше закрываются самописным алгоритмом.
Первоначальное заполнение занимает около 20-30 минут.
Что касается готовых движков, то те, с которыми я работал раньше, не умели искать по подстроке, то есть, были не способны найти "65U790KB" по запросу "65U790K", а это в нашем случае важно. По сути, такое поведение понятно, они создавались для поиска по тексту на естественном языке. Возможно, сейчас кто-то уже так может, но я положился на свой прошлый опыт.
Второй вариант - использовать готовый движок, но с индексом не по словам, а по триграммам. И сначала у нас был именно такой подход, но в какой-то момент перестала устраивать скорость работы.
Есть еще два аргумента против готового:
Свой поиск получился довольно простым по устройству, и его мы полностью контролируем, а не ограничены настройками готового движка. С другой стороны, мы ограничены своими возможностями, и, например, морфологии у нас никогда не будет.
Мы стараемся минимизировать количество инфраструктурных зависимостей. Сейчас такая зависимость только одна - SQL Server. В общем, такой вот keep it simple.
Хорошее замечание, спасибо.
Я даже не знаю, сколько пустых, но давайте попробуем посчитать потенциальную экономию.
Это фрагмент исходного кода .NET 5
Для хранения пустого списка на 64-битной системе потребуется 8 + 4 + 4 = 16 байт. Плюс хранение ссылки на этот список потребует 8 байт, итого 24 байта без учета выравнивания. Потребление памяти с выравниванием я сходу не посчитаю, к сожалению, поэтому оставим так.
Всего у нас 343 000 списков, это дает 8 232 000 байт потенциальной экономии для случаев, когда индекс создали, а использовать не стали.
Думаю, в нашем случае, когда индекс создается в одном экземпляре, экономией 8 мегабайт памяти можно пренебречь ради упрощения кода. С другой стороны, если бы речь шла про переиспользуемую библиотеку, учесть это обязательно нужно.
Возможно, я найду время и оформлю эту идею в виде nuget - пакета, и тогда сделаю ленивую инициализацию.
По сути, мы именно это и сделали, только на уровне триграмм, а не слов.
Можно, на протяжении года так и работало. Потом нас перестала устраивать скорость работы такого подхода.
Нам нужно искать слова с опечатками и просто похожие варианты, и поиск не ограничивается только словами русского / английского языка. Например, на запрос "65U710KB" нужно предложить вариант "65U790KB", если ничего лучшего не было найдено.
Это поиск не для пользователей интернет-магазина, а для администраторов, и такой поиск упрощает их работу.
Мы пока загрузили 20 ГБ памяти, и ядра практически никак не загружены.
Простите, не так вас понял. Да, это можно. Конкретно в нашей ситуации сначала проще докупать память на одном сервере, чем делать масштабирование. До 256 ГБ можно докупить, дальше упираемся в ограничения используемого железа.
Если же делать из этого публичное решение, то конечно, масштабирование необходимо.
Все просто, горизонтальное масштабирование позволит хранить больше данных, но не позволит MS SQL Server быстрее искать по полнотекстовому индексу. Вызов функции Containstable на таком объеме данных занимает 98% времени обработки запроса, то есть, по сути те 2-5 секунд, о которых я писал вначале, и принципиально его не ускорить. Вместо этого мы сделали метод, который работает за 10 миллисекунд, эта часть ускорилась в 200-500 раз.
А что до ограничений памяти сервера, то аренда сервера с 64 гигабайтами стоит 50 евро в месяц. И ещё запас для роста в 2 раза остался.
Я не знаю, при помощи какого инструмента можно добиться такого результата "из коробки".
Перепроверил.
Прошу прощения у всех, кто мне поверил. Вы правы, я действительно посчитал микроминуты вместо микросекунд.
Та же газета в правильном разрешении.
Я не догадался и погуглил. Картинка остроумная.
Если вы тоже не догадались и читаете этот комментарий, рекомендую подумать, задача интересная.
А точно будет 60000 rpm?
Поискал в Гугле, нашел упоминание 18000, 20000 как максимальных оборотов в минуту, и 6150 как оборотов в минуту, на которых достигается максимальная мощность, но это не конкретно plaid.
Спрашиваю потому что 60000 rpm - это очень много, это 1000 оборотов в секунду. По грубым прикидкам в уме при такой скорости вращения большого мотора напряжения в материале выше предела текучести стали. Конечно, есть и другие материалы, но все же непонятно, ради чего нужно преодолевать столько сложностей.
Если понимать 25 микродуговых секунд как 25 микросекунд дуги, линейное разрешение на расстоянии 5800 км составит 42 миллиметра. При стандартной ширине полосы газеты, равной 300 миллиметров, это 7 пикселей в ширину. В общем, вот.
А вместо старшего грузчика? То-то и оно!
Ок, удавили углекислый газ, но что с ним делать дальше? Не хранить же в цистернах под давлением.
Какие вообще есть варианты?
Попробую дать определение определенному поведению для C++20: это поведение, закрепленное в стандарте International Standard ISO/IEC 14882:2020(E) – Programming Language C++.
То, что поведение не меняется со временем, к определенному поведению отношения не имеет, если стандарт не предусматривает однозначного поведения для такой ситуации. Даже если какой-то код ведет себя одинаково с любым известным компилятором и любой известной средой выполнения, но стандарт не предусматривает однозначного поведения в такой ситуации - это все равно неопределенное поведение.
Я не спорю с тезисом про разные проекции, но пример с Африкой и Евразией не понял. На контурных картах, насколько я помню, Евразия была больше Африки. В реальности Евразия больше Африки.
Возможно, вы имели в виду пример с Россией (или СССР) и Африкой. В этом случае, если по памяти, то на карте они примерно одинаковой площади, хотя в реальности Африка значительно больше.