LINUX.ORG.RU

Посоветуйте СУБД


0

1

Для веба под хорошие нагрузки. Было бы здорово, если б с поддержкой шардинга/репликации. Можно NoSQL. Которая умеет быстро делать операции регистронезависимый поиск по подстроке, т.е. с быстрой реализацией аналога SQL выражения LIKE '%something%'. Если будет возможность «нечеткого» поиска (по релевантности), то вообще классно. Кроме поиска СУБД естественно должна поддерживать и другие присущие базам данных функции, такие как добавление, редактирование и выборку с фильтрацией данных :)

Пробовал CouchDB, строя индекс по Map-функции:

function(doc) {
  var i;
  if (doc.title) {
    for (i = 0; i < doc.title.length; i++) {
      emit(doc.title.slice(i), doc);
    }
  }
}

Работает, но индексация очень долгая и БД получается очень огромная. В принципе, расстраивает меня даже не это, а то что на каждый чих приходится писать эти Map-Reduce функции, от которых мозг закипает - сложно делается даже простейший SQL-аналог join.

Посмотрел на MongoDB. Язык запросов понравился, многие вещи делаются проще. Но сходу не нашёл, как там делать поиск по подстроке.

SQL-СУБД индексы на LIKE '%something%' не используют, что приводит тормозам на большой базе.

К чему ещё можно присмотреться?

> SQL-СУБД индексы на LIKE '%something%' не используют, что

приводит тормозам на большой базе.


А для чего вы используете такие запросы? Может лучше Sphinx для поиска заюзать?

Но сходу не нашёл, как там делать поиск по подстроке.


http://www.mongodb.org/display/DOCS/Full+Text+Search+in+Mongo

archimag ★★★
()
Ответ на: комментарий от pi11

О, а как кстати pgpool? Стоит оно того? Планируем вот заюзать. Как оно производительности на запись?

dizza ★★★★★
()
Ответ на: комментарий от dizza

Ну если больше одного сервера то безусловно стоит.
По производительности на запись не тестировал специально, но по ощущениям изменений в скорости не заметно.

Если один сервер БД или нужен _только_ connection pool то лучше pgbouncer.

pi11 ★★★★★
()

Юзай обычную СУБД и не парься. Postgresql/MySQL, пофиг. Что касается нагрузок, то просто не пихай в бд всякую лажу вроде хранимок. Юзай просто как хранилище. Ну и кэширование. И то может не понадобится, если на серваке будет достаточно оперативки.

dizza ★★★★★
()
Ответ на: комментарий от archimag

«Для веба» в 90% достаточно статик генератора :) Может быть и проще, но мне кажется это не та вещь из-за которой стоит запариваться. Впрочем, не думаю что mongodb проще чем рсубд + ORM. Хотя я могу и ошибаться - ничего крупного на NoSQL не делал, только по мелочевке.

dizza ★★★★★
()
Ответ на: комментарий от pi11

Не как раз нужно отказоустойчивость сделать. Как запасной вариант смотрю еще на HA-JDBC, это для жабки такое client-side балансер запросов.

dizza ★★★★★
()
Ответ на: комментарий от archimag

>Звучит как-то странно, ибо та же MongoDB для веба часто просто проще.

Чем проще?

pi11 ★★★★★
()

по LIKE '%something%' ничто быстро искать не будет, да ещё и с маленькими индексами. Нужно переделывать тз.

mashina ★★★★★
()

Пользуйся поисковыми движками. Тот же sphinx умеет здоровенные нагрузки.

daris
()

>SQL-СУБД индексы на LIKE '%something%' не используют
Таки да? А если попробовать использовать не LIKE а полноценный полнотекстовый поиск, который есть, и в mysql, и в postgresql?
Хотя лучше конечно sphinx.

Tark ★★
()
Ответ на: комментарий от mashina

По LIKE не делают, но по отдельным словам в тексте ищут, и там еще морфология учитывается и релевантность.

Tark ★★
()
Ответ на: комментарий от pi11

PostgreSQL+pgpool2+Sphinx search

PostgreSQL как раз и используем сейчас. pgpool2 изучаем, спасибо.

А вот Sphinx пока не ясно как может помочь, он же просто БД реструктурирует, извлекая из текстовых полей отдельные слова и индексируя их, да?

Основная огромная таблица, по которой и нужно делать поиск, и так содержит отдельные слова, иногда 2-4 слова, например:

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

И надо уметь производить поиск по ней очень быстро по подстроке и (желательно) с опечатками в написании. Поможет ли в этом случае sphinx?

dennis_pro
() автор топика
Ответ на: комментарий от dennis_pro

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

trashymichael ★★★
()
Ответ на: комментарий от dennis_pro

ведь и гвозди можно забивать бутылкой. а твой вопрос звучит именно как «поможет ли молоток в забивании гвоздей?», или ты будешь экономить 2гб занимаясь преждевременной оптимизацией и изобретая «оптимизированные» алгоритмы?

trashymichael ★★★
()
Ответ на: комментарий от dennis_pro

>А вот Sphinx пока не ясно как может помочь, он же просто БД реструктурирует, извлекая из текстовых полей отдельные слова и индексируя их, да?

Не только текстовые, любые которые укажете (integer, boolean, etc).

И надо уметь производить поиск по ней очень быстро по подстроке и (желательно) с опечатками в написании. Поможет ли в этом случае sphinx?


Все кроме поиска с опечатками (хотя наверное вручную частые опечатки можно подключить через словарь словоформ).
Скорость поиска очень высокая.

pi11 ★★★★★
()
Ответ на: комментарий от dib2

Хотя если >2ГБ база, скорее всего руки кривые... Или неужели более стотыщьпятьсот ячеек? Так только у гугла, который кстати и использует код SQLite...

moscwich
()
Ответ на: комментарий от moscwich

прикинь, бывает же :)
одна из таблиц, в одном из проектов, у меня сейчас весит ~74млн записей (mysql).

dib2 ★★★★★
()
Ответ на: комментарий от moscwich

>если это не форум и не поисковик...
бывают еще всякие энтерпрайзнутые опердени

dib2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.