Пара комментариев к статье от астронома:
1. Аречибо --> Аресибо, все-таки так принято читать это по-русски.
2. Угасающая природа сигнала и уменьшение его частоты перпендикулярные понятия. Сигнал может уменьшать частоту, но оставаться таким же сильным. Тут имеется в виду, что раньше в SETI@home не было способа выделять сигналы с переменной частотой, а сейчас появился.
3. Не бывает сигналов от звездных скоплений в 500 Мпк от Земли. На таком расстоянии мы можем увидеть лишь галактики, но не звездные скопления в них. Галактика != звездное скопление.
Для подавляющего большинства этого сообщества никакую. Но есть ведь всякие конференции по SETI, которые "нормальные" астрономы не очень жалуют. Думаю, там какие-то картинки с SETI@home показывают постоянно.
Отличное сравнение, спасибо за него. Есть еще интересная возможность быстрого определения приблизительного количества рядов, когда не нужна идеальная точность (такое бывает в случае больших чисел): делать explain запросу при обновленной статистике (в свежих версиях PostgreSQL при включенном автовакууме статистика всегда актуальна) и смотреть на оценку рядов, которую делает планировщик запросов. Цена вопроса миллисекунды.
Может. По сути это просто разовая проверка железа, больше ничего. Как устроена запись на диск? Условно, на примере Linux (в других ОС системные вызовы по-другому называются, но суть одинакова) это происходит так (упрощенно): вы делаете fwrite и пИшите, что хотите, в любых количествах. Потом делаете fsync. Если система вам сказала, что фсинк завершился успешно, значит она _гарантирует_, что данные с этого атомарного мгновения записались в постоянную память. Контроллеры с батареей, как правило (это настраивается) для улучшения производительности, в этот момент атомарно помечают накопившиеся изменения в забекапленной батарейкой памятью, как закоммиченные, но не сбрасывают их на диск. Простые жесткие диски в этот момент переносят данные из кеша устройства в ПЗУ и дожидаются физического окончания работы записывающей головки.
Теперь, если происходит отключение эл-ва в момент, когда fwrite завершен, но не было fsync-а, вы теряете эти данные. Если отключение происходит в момент, когда вызван fsync, но он еще не вернул положительного результата, вы теряете эти данные. Если отключение происходит после завершенного фсинка вы не теряете эти данные. Если они остались в кеше контроллера, после включения питания он сам позаботится о дозаписи фсинкнутых данных на ПЗУ.
Далее, PostgreSQL и другие ACID-совместимые СУБД устроены приблизительно следующим образом. Любое изменение данных представляет собой транзакцию. И транзакция не считается завершенной, пока следующий в самом ее конце вызов fsync не вернул положительного результата. Таким образом при отключении эл-ва в любое мгновение максимум, что вы можете потерять это незавершенные транзакции, которые были открыты в этот момент. А это есть ни что иное, как убедительная уверенность, что у вас не попортятся таблицы, не съедет карма, и не пропадут личные сообщения. Сказочная надежность PostgreSQL устроена именно так.
Единственная возможность для сбоя faulty hardware. У вас может лажануть контроллер или диск. Например, в процессе падения напряжения попортить записывающей головкой блины. Но если этого не происходит в первый раз, значит у вас более-менее надежное железо, которое с большой вероятностью не подведет вас во второй и последующие разы.
какой вы упрямый :) у моих пользователей тоже десятки гигабайт не редкость. но бенчмарк нужен не для моих или ваших пользователей, они с существующего решения не слезут. он нужен для пользователей, которые сомневаются и хотят обосновано выбрать. а у 95% таких база влезает в RAM относительно недорогого сервера. поэтому нескольких гигабайт русской википедии за глаза хватит. давайте лучше придумаем, как сделать дамп, пригодный для вставки во все СУБД.
ммм, это ирония про "где-то слышал", надеюсь? как, имея чертовски ненадежную MySQL, можно использовать контроллеры без батарей в серьезном проекте? да все мало-мальски пристойные карты уже давно едут с собственной памятью и батарейками. про MySQL я вам не скажу, эта база и на ровном месте побиться умеет, а вот для ACID-совместимых баз _исправный_ контроллер с батарейкой является гарантией консистентного состояния базы после восстановления. контроллер сам сделает sync на диск из своей памяти, а база накатит из журнала необходимые транзакции.
кое-кто даже при покупке нового железа с PostgreSQL такие штуки вытворяет для проверки дисков и карточки: запускает тест на очень активную запись в базу и руками из розетки штепсель сервера выдергивает. а после успешного ребута ставит галку в ведомость "дисковая подсистема сервера #n проверена".
почему все так волнуются за глюки в хабре? в нормальных СУБД и приложениях аварийное выключение питания сервера не приводит ни к каким сбоям (если железо не пострадало). а здесь, видимо, все чуют MySQL и от этого появляется тревога за карму и личные сообщения :)
эраундми, соседи-онлайн... про миртесен, который живее всех живых и крупнее всех остальных картоориентированных стартапов на хабре говорить, видимо, непринято :) мест там, кстати, достаточно уже
бенчмаркать лучше не гигантские базы, которых у пользователей никогда не будет, а более-менее реалистичные объемы. иначе интерес будет чисто академический. поэтому русская википедия мне кажется более интересной в этом отношении.
так а сколько всего документов в индексе? все же как-то странно у вас: один и тот же запрос, один и тот же индекс, а матчей разное количество. так разве бывает? :)
каков размер индекса и сколько в нем позиций? мой запрос, кстати, не содержит лимита. с лимитом на 1000 мс быстрее. правильно я понимаю, что искалось слово 'the'? это же стоп-слово! плюс к тому, вы на порядок уменьшили result set это нечестно. 50 тыс. рядов у меня выбираются и сортируются с лимитом в 1000 за 150 мс. и это с медленным индексом. сейчас сделаю быстрый.
Краткий список возможностей полнотекстового поиска в PostgreSQL из основного, что могу вспомнить на бегу
- 2 типа индексов: обобщенное поисковое дерево (быстрые апдейты, сравнительно медленные выборки) и обратный индекс (очень быстрые выборки, медленные апдейты)
- онлайн-обновление индекса без задержки
- морфология на основе Ispell (поддерживается множество языков)
- поддержка пользовательских словарей: стоп-слова, синонимы, тезаурус, словари регулярных выражений и др.
- онлайн-переписывание запросов (когда нет возможности переиндексировать все целиком)
- линейное масштабирование практически до произвольных масштабов (так как ранкинг локальный), известны production-инсталляции размером в 100 TB
- релевантность определяется с учетом расстояния между словами
- поддержка тегов внутри индекса (можно назначать разные веса заголовку и телу новости, например, или искать только по заголовкам внутри индекса)
- возможность highlight
- встроен в ядро СУБД, не нужно дополнительно инсталлировать, поэтому будет на хостингах
- индексная поддержка префиксного поиска 'abc%' и других LIKE-ов, например '%abc%'
- встроенные инструменты сбора статистики по индексу
- гибкая система конфигурации и управления порядком обработки запросов
- булевы выражения в полнотекстовых запросах, возможность сочетать полнотекстовые запросы с остальными возможностями СУБД
У меня такие цифры получаются quick & dirty если:
~10^6 строк в индексе, запрос возвращает 6*10^5 строк, сортировка по атрибуту. Все вместе на Xeon 2.4 (load average сервера от других процессов около 4 в этот момент) занимает 2300 мс, из которых индекс-скан ~200 мс, heap scan (из-за того, что индекс гистовый lossy) еще 700 мс, дальше quicksort-сортировка около 1200 мс. Но это не обратный индекс. С обратным будет быстрее. С сортировкой тоже можно что-то придумать.
Извините, я не хотел выглядеть offensive. Я лично уважаю вас и вашу разработку, не так много действительно популярного софта пишется с участием российских разработчиков. Ну и, разумеется, tsearch умеет не все и ни в коем случае не является панацеей.
Барт мне больше объективность, чем друг все же :) За tsearch мне несколько обидно потому, что он объективно очень хорош, но с популярностью его зачастую незаслуженно обходят. Sphinx-у легче, связь с MySQL очень помогает, по моему мнению.
Кстати, если вы находитесь в Москве, приходите к нам на встречу PostgreSQL-сообщества, мы хотим устроить tutorial по настройке полнотекстового поиска для широкой публики. Там же и с бенчмарками можно разобраться. С вами было бы интересно лично побеседовать.
Ну а лист сравнения фич я бы все-таки сделал, чтобы пользователям было бы легче ориентироваться.
1. Аречибо --> Аресибо, все-таки так принято читать это по-русски.
2. Угасающая природа сигнала и уменьшение его частоты перпендикулярные понятия. Сигнал может уменьшать частоту, но оставаться таким же сильным. Тут имеется в виду, что раньше в SETI@home не было способа выделять сигналы с переменной частотой, а сейчас появился.
3. Не бывает сигналов от звездных скоплений в 500 Мпк от Земли. На таком расстоянии мы можем увидеть лишь галактики, но не звездные скопления в них. Галактика != звездное скопление.
Теперь, если происходит отключение эл-ва в момент, когда fwrite завершен, но не было fsync-а, вы теряете эти данные. Если отключение происходит в момент, когда вызван fsync, но он еще не вернул положительного результата, вы теряете эти данные. Если отключение происходит после завершенного фсинка вы не теряете эти данные. Если они остались в кеше контроллера, после включения питания он сам позаботится о дозаписи фсинкнутых данных на ПЗУ.
Далее, PostgreSQL и другие ACID-совместимые СУБД устроены приблизительно следующим образом. Любое изменение данных представляет собой транзакцию. И транзакция не считается завершенной, пока следующий в самом ее конце вызов fsync не вернул положительного результата. Таким образом при отключении эл-ва в любое мгновение максимум, что вы можете потерять это незавершенные транзакции, которые были открыты в этот момент. А это есть ни что иное, как убедительная уверенность, что у вас не попортятся таблицы, не съедет карма, и не пропадут личные сообщения. Сказочная надежность PostgreSQL устроена именно так.
Единственная возможность для сбоя faulty hardware. У вас может лажануть контроллер или диск. Например, в процессе падения напряжения попортить записывающей головкой блины. Но если этого не происходит в первый раз, значит у вас более-менее надежное железо, которое с большой вероятностью не подведет вас во второй и последующие разы.
кое-кто даже при покупке нового железа с PostgreSQL такие штуки вытворяет для проверки дисков и карточки: запускает тест на очень активную запись в базу и руками из розетки штепсель сервера выдергивает. а после успешного ребута ставит галку в ведомость "дисковая подсистема сервера #n проверена".
limit 1000 срезает все до 40 мс
ты все правильно понимаешь :)
- 2 типа индексов: обобщенное поисковое дерево (быстрые апдейты, сравнительно медленные выборки) и обратный индекс (очень быстрые выборки, медленные апдейты)
- онлайн-обновление индекса без задержки
- морфология на основе Ispell (поддерживается множество языков)
- поддержка пользовательских словарей: стоп-слова, синонимы, тезаурус, словари регулярных выражений и др.
- онлайн-переписывание запросов (когда нет возможности переиндексировать все целиком)
- линейное масштабирование практически до произвольных масштабов (так как ранкинг локальный), известны production-инсталляции размером в 100 TB
- релевантность определяется с учетом расстояния между словами
- поддержка тегов внутри индекса (можно назначать разные веса заголовку и телу новости, например, или искать только по заголовкам внутри индекса)
- возможность highlight
- встроен в ядро СУБД, не нужно дополнительно инсталлировать, поэтому будет на хостингах
- индексная поддержка префиксного поиска 'abc%' и других LIKE-ов, например '%abc%'
- встроенные инструменты сбора статистики по индексу
- гибкая система конфигурации и управления порядком обработки запросов
- булевы выражения в полнотекстовых запросах, возможность сочетать полнотекстовые запросы с остальными возможностями СУБД
~10^6 строк в индексе, запрос возвращает 6*10^5 строк, сортировка по атрибуту. Все вместе на Xeon 2.4 (load average сервера от других процессов около 4 в этот момент) занимает 2300 мс, из которых индекс-скан ~200 мс, heap scan (из-за того, что индекс гистовый lossy) еще 700 мс, дальше quicksort-сортировка около 1200 мс. Но это не обратный индекс. С обратным будет быстрее. С сортировкой тоже можно что-то придумать.
У вас как?
Барт мне больше объективность, чем друг все же :) За tsearch мне несколько обидно потому, что он объективно очень хорош, но с популярностью его зачастую незаслуженно обходят. Sphinx-у легче, связь с MySQL очень помогает, по моему мнению.
Кстати, если вы находитесь в Москве, приходите к нам на встречу PostgreSQL-сообщества, мы хотим устроить tutorial по настройке полнотекстового поиска для широкой публики. Там же и с бенчмарками можно разобраться. С вами было бы интересно лично побеседовать.
Ну а лист сравнения фич я бы все-таки сделал, чтобы пользователям было бы легче ориентироваться.