Web programming: Indexed tar files
.
Большинство веб-программистов, когда речь заходит о хранении данных для вебсайта, автоматически вводят базу данных. Это - тренированная реакция, как у собаки Павлова, тиражированная в миллионах экземпляров по всему миру, и она не проходит через мыслительные фильтры.
Действительно, если на секунду задуматься, не удивительно ли:
Большинство веб-программистов, когда речь заходит о хранении данных для вебсайта, автоматически вводят базу данных. Это - тренированная реакция, как у собаки Павлова, тиражированная в миллионах экземпляров по всему миру, и она не проходит через мыслительные фильтры.
Действительно, если на секунду задуматься, не удивительно ли:
- создали веб сервер ( Read more... )
Reply
На получении по индексу 3 килобайтного блоба (аналогично указанному примеру) уйдет где-то 20 миллисекунд для первых миллионов записей.
И зачем нужен tar?
БД проигрывает ФС при отдаче больших объемов данных, так как не поддерживает некоторые системные фенечки для этого, но схема с tar точно так же ничего такого не поддерживает, поэтому быстрее точно не будет.
Брр, 0.2 секунды на запрос, ужас какой.
Reply
НЕТ поиск по подстрочке не обеспечит ни один индекс. Для использования индекса надо знать ТОЧНОЕ ЗНАЧЕНИЕ поискового термина.
Если я не помню (типичный сценарий) точного написания имени пользователя ЖЖ, но помню подстрочку "мнямня_алекс" ?
Любая база данных в таком случае будет просто сканировать столбец, применяя к нему те же самые регэкспы.
Reply
Онаним, Вы сильно ошибаетесь. Посмотрите на запросы вида " .. LIKE 'qwerty%'" в нормальных базах данных (хотя бы в oracle).
Reply
Вы НЕ ПОНИМАЕТЕ, что делает программа, и относитесь к БД как пейзанин к грому с молниями - это Бог на небе едет в колеснице.
Вы не знаете как устроены индексы, и подменяете знание отсылом к "нормальным базам данных" (эквиваленту "цивилизованной страны" из газеты).
Reply
Reply
Reply
Reply
А для типичных сценариев есть типичные решения. В любом случае, поиск по индексу - он быстрее поиска по файлу. Да и регэкспы обычно не использует - ситуация, где конечный пользователь вводит регэкспы - достаточно редкая.
Для 30 000 элементов в индексе - скорее всего те же 20-30 миллисекунд (завтра поставлю эксперимент, поищу какую-нибудь табличку поменьше).
Да, кстати, в ЖЖ такой возможности я что-то не нашел :) Только поиск по точному имени, да и тот тормозит.
Если же нужно искать по всем текстам сайта - то тут уже нужно смотреть в сторону очень специальных решений ;)
Я к чему - предложенное решение практически всегда уступает или БД или специальным поисковым решениям - тогда зачем оно нужно?
Reply
Более того, в моем примере создан текстовый каталог содержимого ТАРа. Никто не мешает из него сляпать (опять-таки стандартными utilities, поставляемыми с ОС) и реальный индекс. Одна команда из еще строк 5 - 10 от силы - скрипта.
Reply
Вместо стандартного, масштабируемого, дешевого в разработке и поддержке решения предлагается нестандартное, немасштабируемое, дорогое в разработке и в поддержке, да еще и медленное решение.
В чем смысл?
Кстати, если внимательно подсчитать, то уже далеко не 20-30 строчек, 20-30 строчек ушло только на поиск по ключу (одна строчка в любой БД), а есть еще задачи добавления данных, создания бэкапов, оптимизации, аудита, контроля производительности и т.д.
Т.е. для личной страницы автора - пойдет, каждый выбирает себе сложности сам. Для коммерческого использования - нафиг надо.
Reply
Reply
Reply
Reply
Reply
Избавиться от тяжелого груза в самом частом случае - что может быть лучше?
Reply
Leave a comment