База данных Mysql Вопрос о больших столбцах - PullRequest
1 голос
/ 17 апреля 2010

У меня есть таблица с 100.000 строками, и вскоре она будет удвоена. Размер базы данных в настоящее время составляет 5 ГБ, и большинство из них идет в один конкретный столбец, который является текстовым столбцом для файлов PDF. Мы ожидаем, что через пару месяцев у нас будет 20-30 ГБ или, возможно, 50 ГБ базы данных, и эта система будет часто использоваться.

У меня есть пара вопросов относительно этой настройки

1-) Мы используем innodb для каждой таблицы, включая таблицу пользователей и т. Д. Лучше ли использовать myisam в этой таблице, где мы храним текстовые версии файлов PDF? (с точки зрения использования памяти / производительности)

2-) Мы используем Sphinx для поиска, однако данные должны быть получены для выделения. Выделение выполняется с помощью sphinx API, но нам все же нужно получить 10 строк, чтобы снова отправить их в Sphinx. Эти 10 строк могут выделять 50 МБ памяти, что довольно много. Поэтому я планирую разбить эти PDF-файлы на куски по 5 страниц в базе данных, поэтому эти 100 000 строк будут иметь размер около 3-4 миллионов строк, а через пару месяцев вместо 300 000–350 000 строк у нас будет 10 миллионов. строки для хранения текстовой версии этих файлов PDF. Однако мы будем извлекать меньше страниц, поэтому снова вместо того, чтобы извлекать 400 страниц для отправки Sphinx для выделения, мы можем извлечь 5 страниц, и это сильно повлияет на производительность. В настоящее время, когда мы ищем термин и извлекаем файлы PDF, которые имеют более 100 страниц, время выполнения составляет 0,3-0,35 секунды, однако если мы извлекаем файлы PDF, которые имеют менее 5 страниц, время выполнения сокращается до 0,06 секунды, и это также использует меньше памяти.

Как вы думаете, это хороший компромисс? У нас будет миллион строк вместо 100–200 тысяч строк, но это сэкономит память и улучшит производительность. Это хороший подход для решения этой проблемы, и есть ли у вас идеи, как преодолеть эту проблему?

Текстовая версия данных используется только для индексации и выделения. Итак, мы очень гибкие.

Редактировать: мы храним pdf файлы в нашем облаке, однако для подсветки поиска нам нужно получить текстовую версию pdf файла и передать ее в Sphinx, затем Sphinx возвращает выделенный 256-символьный текст. Чтобы проиндексировать PDF-файлы, нам нужно вставить их в базу данных, потому что они также содержат дополнительные метаданные, такие как теги описания и заголовок, и нам нужно связать их для поисковой системы. Если мы индексируем txt-файлы или pdf-файлы с файлового сервера, невозможно получить другие данные из базы данных и связать их с этими txt-файлами в поисковой системе. Таким образом, мы все еще храним PDF-файлы в нашем облаке, но текстовая версия также должна быть в нашей базе данных, чтобы индексировать заголовок и описание тега. Это разные таблицы, но они также должны быть в базе данных.

Спасибо

Ответы [ 3 ]

0 голосов
/ 17 апреля 2010

Звучит как очень плохой выбор технологии. Если вы можете замедлить рост, чтобы хранить все в памяти (доступной до 128 ГБ или около того) или разделить для большего размера, вы можете ограничить передачу по сети.

[править] Если PDF-файлы находятся на диске, а не в оперативной памяти, ваш диск должен быть доступен. Если у вас нет SSD, вы можете сделать это 50 раз / секунду / диск. Пока PDF меньше, чем дорожка диска, разделение не очень интересно. Если вы разбили PDF-файлы, а затем вам нужен доступ ко всем частям, вам может потребоваться загрузка из нескольких дорожек, что сильно замедляет работу.

Работа с большими документами с помощью RDBM в многопользовательской настройке не очень хорошая идея, с точки зрения производительности.

0 голосов
/ 20 апреля 2010

Используйте Solr, можно индексировать текстовые файлы с их метаданными из базы данных. Я переключил поисковик на Solr.

0 голосов
/ 17 апреля 2010

Похоже, вам не нужно извлекать весь ваш файл PDF каждый раз, когда вы нажимаете на строку для этого файла PDF.

Вы отделяете метаданные о ваших файлах pdf от самого файла? у вас определенно не должно быть здесь только одного стола. вам может понадобиться что-то вроде таблицы pdf_info со 100 столбцами (у вас действительно так много метаданных? почему 100 столбцов?) и внешним ключом для таблицы pdf_files, содержащей фактический текст для файлов. затем вы можете поэкспериментировать, возможно, с созданием таблицы info innodb и таблицы files myisam.

ИМХО: есть много, много причин НЕ хранить ваш pdf файл в базе данных mysql. я бы просто сохранил пути к файлам в SAN или какой-то другой механизм распространения файлов. sql хорош для хранения любых абстрактных данных, и файлы, безусловно, относятся к этой категории. но файловые системы специально предназначены для хранения файлов, а веб-серверы специально предназначены для максимально быстрой доставки этих файлов. так что ... просто подумать.

...