Для показа юзеру что 1000, что 100000 документов это одинаковое количество - "слишком много", поэтому для оценки качества нужны таки промаркированные запросы.
Лимиты делали?
Кэш не грели, слова для запросов каждый раз брали рандомом, обычно по 1000 запросов (если они работали слишком медленно - уменьшали до 100)
можно все-таки дисперсию или min-max время увидеть?
И попробуйте на каком-то одном списке тестировать все движки (а то мало ли, вдруг кто-то не стал парсить xml и названия тегов стали словами, причем супер частыми, и такое слово попалось в запросе).
Странная статья. Где описание методологии? Сделали непонятно что, получили какие-то результаты - толку от них кому-то?
(ниже акцент на Postgres, т.к. с ним я хорошо знаком, но сами вопросы, думаю, актуальны для более-менее всех движков)
Версии ПО? (ссылка на postgres fts в англ версии ведет на доки от 9.5, что наводит на подозрения)
Как конфигурировали? Конкретно по postgres: основные параметры postgresql.conf? Какого типа индексы (gist/gin)? Конфигурация FTS? (вообще, некоторые утверждения ваши вызывают недоумение, например, про поддержку языков: вы точно отличаете языки от кодировок? Вы же дочитали в документации postgres до раздела про словари FTS?)
Запросы - код, плз. Какие именно ключевые слова использовались и в каком количестве? Надеюсь, хотя бы одинаковые для всех движков? Запросы выдают хотя бы примерно одинаковый результат? Ранжирование было?
Техническая достоверность: БД в память помещается? прогревали кеш? запросы one term / 3 term OR - с одними ключевиками (очень большие сомнения конкретно для postgres вызывают именно эти результаты - хотелось бы видеть конкретику)?
Статистическая достоверность - сколько раз прогоняли? дисперсия какая?
Оценка результатов поиска (выше уже про качество писали, но хотя бы количественно - если один нашел 100 документов, а другой 10000 по одному и тому же запросу - сравнивать как-то некорректно).
При помощи аналогичных вычислений можно показать, что на самом деле обертоны — это целые кратные основной частоты
"Поверьте на слово, в конце концов, вы же не побежите ради этого покупать книженцию за 245 долларов", ага.
Вообще-то, собственные частоты круглой мембраны - это нули функций Бесселя, которые вообще ни разу не кратны друг другу, даже для простейшего случая радиальных колебаний (функция J0)
БД размером 3GB, дамп в формате plain весит порядка 14-17GB.
Эм… Что это такие у вас за данные?
Куча огромных текстовых полей, что ли? Разве что в этом случае внутреннее сжатие даст такую разницу (и то сомневаюсь).
Несовпадение количество строк в некоторых таблицах в исходной и целевой БД, после выполнения pg_restore (Исходная БД не использовалась в процессе копирования, если, что ).
не верю (с)
Имхо, лучше бы вы поисследовали эту проблему и про нее написали статью. Было бы гораздо полезнее разобраться, если что-то такое действительно может иметь место.
Но plain огромный размер дампа.
Включите сжатие (custom/directory сжаты по умолчанию, отсюда вся разница).
К слову об экономии места: копия БД весит заведомо больше, чем любой дамп. Так что сомнительная у вас экономия даже на этом.
Плюс простота организации и управления хранением
Не знаю…
Если свежесть данных некритична (или БД можно отключить от пользователей), что-то проще dump/restore придумать сложно.
Если важна полнота данных (как, например, при онлайн миграции на новую версию), то дамп схемы + логическая репликация с живой БД — канонический способ, описанный примерно везде.
Во вторых-и это самое неприятное, были случаи несовпадения исходной и целевой БД при восстановлении из дампа.
Какие еще несовпадения? Вы ожидали совпадения на какой момент?
В начале дампа pg_dump начинает serializable транзакцию, все, что произошло в исходной БД после, в дамп не попадает.
Думаете, копия через create database как-то по-другому работает?
В третьих-время, сначала на создание дампа, потом на восстановление БД из дампа.
Неужели репликация быстрее? Хмм…
В итоге единственное преимущество — экономия на месте для дампов (временных).
Да, с zheap что-то совсем заглохло… У вас там никто не в курсе, какие планы?
Зато MERGE в PG15, видимо, все же будет.
Мне лично еще очень нравится патч Incremental Materialized View Maintenance. В свое время в Oracle активно использовали подобную фичу в сочетании с DBLINK.
Шекспир очень часто переходит на прозу, в то же Гамлете, когда не остается ни поэтической формы, ни размера. Не говоря уже про рифму — ее у Шекспира и так днем с огнем не найдешь.
Свобода высказываний и мнений означает что вам не имеют право вредить при вашей деятельности, но не означает что вам все обязаны с ней помогать (даже за деньги).
Вам, наверное, знакомо понятие «сетевой нейтралитет»?
Следует ли провайдеру отключить мне интернет, если он не согласен с байтами, которые я пересылаю по его проводу?
Желающие получают возможность услышать вашу точку зрения и факты, что вы желаете им сообщить
Теоретически-то могут, да только меня (точнее, лирического героя-астролога, которого придумали вы) уже дискриминировали, лишили современных средств коммуникации/нормальных человеческих условий работы с аудиторией и вынуждают партизанить.
В случае с ограничением свободы слова ...
Есть государственное ограничение свободы слова, которое может не стесняться. А есть… ну прям на примерах:
> приходят контролирующие органы и закрывают его по надуманным предлогам
приходит сотрудник Твиттера и под надуманным предлогом банит Трампа
> в квартире выключают электричество и ломают дверь
Amazon выключает хостинг Parler
Ок, арестовывать пока не могут.
Вообще, конечно, аргумент у вас в стиле «ну не убили же, а че такого?».
Знаете, в свете недавних событий озвученная вами неновая и, в общем, правильная мысль как-то заметно обессмысливается.
Что если вам с вашей конференцией по астрологии отказывают последовательно буквально все площадки? Кому-то не нравится ваша повестка, у кого-то вдруг трубу прорвало. А в ответ на ваше недоумение вам предлагается строить свой конференц-зал.
Я очень сомневаюсь, что из-за причинной связи допустимо менять залог.
В данном случае спроный вопрос: щит сам отсоединился или был отсоединен.
Но сравните, например: has killed/has been killed
Да вот не осиливает:
(cap_net_raw, setuid)
А для чего нужны стигматы святой Терезе? Они ведь ей тоже не нужны. Но они ей желанны. – Вот-вот! (с)
Челенж такой.
Потому что нужны десятичные цифры. Сконвертировать потом из двоичной в десятичную, пожалуй, задача вычислительно более сложная
Ничоси, чудеса да и только :O
https://en.wikipedia.org/wiki/Double-precision_floating-point_format#Precision_limitations_on_integer_values
Лимиты делали?
можно все-таки дисперсию или min-max время увидеть?
И попробуйте на каком-то одном списке тестировать все движки (а то мало ли, вдруг кто-то не стал парсить xml и названия тегов стали словами, причем супер частыми, и такое слово попалось в запросе).
Странная статья. Где описание методологии? Сделали непонятно что, получили какие-то результаты - толку от них кому-то?
(ниже акцент на Postgres, т.к. с ним я хорошо знаком, но сами вопросы, думаю, актуальны для более-менее всех движков)
Версии ПО? (ссылка на postgres fts в англ версии ведет на доки от 9.5, что наводит на подозрения)
Как конфигурировали? Конкретно по postgres: основные параметры postgresql.conf? Какого типа индексы (gist/gin)? Конфигурация FTS?
(вообще, некоторые утверждения ваши вызывают недоумение, например, про поддержку языков: вы точно отличаете языки от кодировок? Вы же дочитали в документации postgres до раздела про словари FTS?)
Запросы - код, плз. Какие именно ключевые слова использовались и в каком количестве? Надеюсь, хотя бы одинаковые для всех движков? Запросы выдают хотя бы примерно одинаковый результат? Ранжирование было?
Техническая достоверность: БД в память помещается? прогревали кеш? запросы one term / 3 term OR - с одними ключевиками (очень большие сомнения конкретно для postgres вызывают именно эти результаты - хотелось бы видеть конкретику)?
Статистическая достоверность - сколько раз прогоняли? дисперсия какая?
Оценка результатов поиска (выше уже про качество писали, но хотя бы количественно - если один нашел 100 документов, а другой 10000 по одному и тому же запросу - сравнивать как-то некорректно).
а почему должна? рациональные обертона там только для мод (n,0)/(0,m) получаются
"Поверьте на слово, в конце концов, вы же не побежите ради этого покупать книженцию за 245 долларов", ага.
Вообще-то, собственные частоты круглой мембраны - это нули функций Бесселя, которые вообще ни разу не кратны друг другу, даже для простейшего случая радиальных колебаний (функция J0)
Эм… Что это такие у вас за данные?
Куча огромных текстовых полей, что ли? Разве что в этом случае внутреннее сжатие даст такую разницу (и то сомневаюсь).
Имхо, лучше бы вы поисследовали эту проблему и про нее написали статью. Было бы гораздо полезнее разобраться, если что-то такое действительно может иметь место.
Включите сжатие (custom/directory сжаты по умолчанию, отсюда вся разница).
К слову об экономии места: копия БД весит заведомо больше, чем любой дамп. Так что сомнительная у вас экономия даже на этом.
Не знаю…
Если свежесть данных некритична (или БД можно отключить от пользователей), что-то проще dump/restore придумать сложно.
Если важна полнота данных (как, например, при онлайн миграции на новую версию), то дамп схемы + логическая репликация с живой БД — канонический способ, описанный примерно везде.
Какие еще несовпадения? Вы ожидали совпадения на какой момент?
В начале дампа pg_dump начинает serializable транзакцию, все, что произошло в исходной БД после, в дамп не попадает.
Думаете, копия через create database как-то по-другому работает?
Неужели репликация быстрее? Хмм…
В итоге единственное преимущество — экономия на месте для дампов (временных).
Зато MERGE в PG15, видимо, все же будет.
Мне лично еще очень нравится патч Incremental Materialized View Maintenance. В свое время в Oracle активно использовали подобную фичу в сочетании с DBLINK.
ОпроверготрицаетКогда уже новостники разберутся в паре простых глаголов?..
Зря не говорили. Ниже написал, но повторю: неграм коворкинг может отказать по причине того, что они негры?
Публичная оферта? Не слышали? Дискриминация? Не слышали?
Может магазин не пускать негров или геев, скажем, по своему усмотрению?
Удивительно, до чего можно договориться…
Вам, наверное, знакомо понятие «сетевой нейтралитет»?
Следует ли провайдеру отключить мне интернет, если он не согласен с байтами, которые я пересылаю по его проводу?
Теоретически-то могут, да только меня (точнее, лирического героя-астролога, которого придумали вы) уже дискриминировали, лишили современных средств коммуникации/нормальных человеческих условий работы с аудиторией и вынуждают партизанить.
Есть государственное ограничение свободы слова, которое может не стесняться. А есть… ну прям на примерах:
> приходят контролирующие органы и закрывают его по надуманным предлогам
приходит сотрудник Твиттера и под надуманным предлогом банит Трампа
> в квартире выключают электричество и ломают дверь
Amazon выключает хостинг Parler
Ок, арестовывать пока не могут.
Вообще, конечно, аргумент у вас в стиле «ну не убили же, а че такого?».
Пока это происходит не с вами
Что если вам с вашей конференцией по астрологии отказывают последовательно буквально все площадки? Кому-то не нравится ваша повестка, у кого-то вдруг трубу прорвало. А в ответ на ваше недоумение вам предлагается строить свой конференц-зал.
В данном случае спроный вопрос: щит сам отсоединился или был отсоединен.
Но сравните, например: has killed/has been killed