Тоже верно. Но и опровержение опасений (их обоснованность каждый для себя может взвесить сам) по принципу "ну вот когда случится, тогда и поговорим" - тоже такое себе.
Все эти советы про "не использовать нестед" вытекают из того факта, что "под капотом" никакого "нестед" нету, и по сути если у вас один документ с сотней "объектов" в нестед - внутри вы просто получите 101 документ. При переходе от хранения в виде вложенных объектов к хранению по документу на строку вы, по сути, получили ровно ту же картинку внутри. Ну, родительские документы убрались.
В таких условиях серьёзный выигрыш по производительности индексации может получиться только за счёт того, что наиболее частый тип изменений - это всё же изменение одной строки, и вы только её и переиндексируете вместо всего документа.
Но что у вас происходит когда, например, в большой документ вставляется новая строка в начало? Или аналогично удаляется?
Ещё нестед даёт консистентное обновление документа в индексе, а вы от него избавились. Т.е. конкретно сейчас при высокой нагрузке и большом объёме изменений в одном документе вы можете получить ситуацию, что в поисковом индексе у вас половина строк старые а половина - новые. Вы что-то планируете с этим делать, или для вас это не критично?
Автокомплит хорошо делается через запись тегов как nested с одним полем + edge-ngram. Это, конечно, не совсем саджесты, но оно выходит гораздо гибче в итоге.
Ну да, конечно. Там получается в итоге просто последовательно несколько SSI-тегов со ссылками на соответствующие куски/локейшны. И между ними если надо можно вставлять всё, что душе угодно — nginx корректно всё обрабатывает. На другом проекте по тому же принципу менялась иконка в exe-файле — подготовленные блоки + рассчитанные куски секции ресурсов, заголовки, контрольные суммы, и т.п. PHP отдавал nginx-у мешанину из байтиков и ssi-тегов, а тот уже всё собирал по мере отдачи файла.
Т.е. например если юзер прерывал загрузку в самом начале nginx уже не читал следующие блоки с диска.
Приходилось делать подобную систему. Там файлы для «упаковки» собирались из достаточно больших блоков (до 3Гб макс, файл чуть меньше 4Гб макс — ограничение зипа), и часть блоков была динамическая. Пересчитывать crc для всего файла на лету при таких размерах, понятно, не вариант. :)
Рассчитанные crc всех статических блоков хранились, для динамических считались в процессе генерации и подгонялись так, чтобы общий crc файла сходился.
Отдавалось всё это через nginx с использованием SSI, в итоге пхп на выходе выдавал динамические блоки + SSI-разметку для nginx, а тот уже сам «собирал» итоговый файл из разных блоков с диска по мере необходимости.
Точно так же потом собирался и рар-архив без сжатия.
Ещё таймстэмпы, конечно, реальные были, и куча всего другого :)
И докачка была, с вычислением смещения и отдачей только нужного куска.
Зип со сжатием тоже делал, но для файлов поменьше. Теоретически, его тоже можно делать с предрассчитанными «блоками» (при аналогичной задаче «сборки» файла из блоков), надо поковыряться немного с кишками deflate для уточнения, но большие всё равно были уже жатые так что необходимости в этом так и не возникло.
Всё собирался статью писать, но не думаю, что дойдут руки… Так что если вдруг интересны какие-то детали…
Ну, если совсем грубо — то никто не мешает сделать ровно то же самое на любом друом языке (включая python/ruby), только без сахара в виде вынесения единственного публичного метода класса в интерфейс и проверки типов. Можно точно так же определить соглашение, точно так же реализовать это соглашение в классах, точно так же подменять конкретную реализацию, и т.п. Язык в этом никак не поможет, да, но сделать это всё равно можно, и кода будет написано плюс-минус столько же.
У них есть какая-то версия. Она распечатана на бумаге.
Потом её меняют, возможно не один раз, и печатают снова. От чего изменения считать и показывать?
Тоже верно. Но и опровержение опасений (их обоснованность каждый для себя может взвесить сам) по принципу "ну вот когда случится, тогда и поговорим" - тоже такое себе.
...
== Вы находитесь здесь ==
...
Интересный пример использования. :)
Все эти советы про "не использовать нестед" вытекают из того факта, что "под капотом" никакого "нестед" нету, и по сути если у вас один документ с сотней "объектов" в нестед - внутри вы просто получите 101 документ. При переходе от хранения в виде вложенных объектов к хранению по документу на строку вы, по сути, получили ровно ту же картинку внутри. Ну, родительские документы убрались.
В таких условиях серьёзный выигрыш по производительности индексации может получиться только за счёт того, что наиболее частый тип изменений - это всё же изменение одной строки, и вы только её и переиндексируете вместо всего документа.
Но что у вас происходит когда, например, в большой документ вставляется новая строка в начало? Или аналогично удаляется?
Ещё нестед даёт консистентное обновление документа в индексе, а вы от него избавились. Т.е. конкретно сейчас при высокой нагрузке и большом объёме изменений в одном документе вы можете получить ситуацию, что в поисковом индексе у вас половина строк старые а половина - новые. Вы что-то планируете с этим делать, или для вас это не критично?
Автокомплит хорошо делается через запись тегов как nested с одним полем + edge-ngram. Это, конечно, не совсем саджесты, но оно выходит гораздо гибче в итоге.
Т.е. например если юзер прерывал загрузку в самом начале nginx уже не читал следующие блоки с диска.
Рассчитанные crc всех статических блоков хранились, для динамических считались в процессе генерации и подгонялись так, чтобы общий crc файла сходился.
Отдавалось всё это через nginx с использованием SSI, в итоге пхп на выходе выдавал динамические блоки + SSI-разметку для nginx, а тот уже сам «собирал» итоговый файл из разных блоков с диска по мере необходимости.
Точно так же потом собирался и рар-архив без сжатия.
Ещё таймстэмпы, конечно, реальные были, и куча всего другого :)
И докачка была, с вычислением смещения и отдачей только нужного куска.
Зип со сжатием тоже делал, но для файлов поменьше. Теоретически, его тоже можно делать с предрассчитанными «блоками» (при аналогичной задаче «сборки» файла из блоков), надо поковыряться немного с кишками deflate для уточнения, но большие всё равно были уже жатые так что необходимости в этом так и не возникло.
Всё собирался статью писать, но не думаю, что дойдут руки… Так что если вдруг интересны какие-то детали…
Потом её меняют, возможно не один раз, и печатают снова. От чего изменения считать и показывать?