и не только полнотекстового. Это прежде всего машины построения индекса, по которому можно осуществлять быстрый поиск. Яндекс-машина плохо управляема, сфинкс более оптимальное решение. Мы используем сфинкс. Я с ним не работал, ничего не подскажу.
что тебе мешает добавить поле City?
много место оно не съест, а вот засвопить таблицу cityes он сможет. Ладно, будем надеяться, что у нас сервер достаточно по ресурсам мощный, но вместо одного буфера — будет выделено два — это доп память, потратится время на слияние. микросекунды… но когда речь идет о нагрузках — то боремся и за микросекунды.
мухи отдельно, котлеты отдельно. забыли слово проксирование.
если вопрос про mongodb — то это к автору топика.
я делюсь информацией, как это делается в проектах деци-миллионниках.
шардинг — это распределение данных на разных физических носителях. распределение может быть по разным признакам. В данной теме БД я не затрагивал, а имелось ввиду файловое хранилище. Хочешь обсуждать шардинг БД, wellcome в соседний топик.
контент льется на два стораджа одновременно. Для надежности. А забирается с одного. В случае выхода одного из серверов — он забирается с другого. что тут непонятного!
ну, а теперь предложи схему, как забирать контент, если выйдет файловый-сервер?
про интенсивность мемкеша не скажу — не замерял
да, мемкеш имеет болезнь на запись — это заметно. Боремся расширением, у нас под него отдельный сервер. И еще мы его пропатчили, так что каждое последующее чтение прлонгирует жизнь элемента кеша на тоже время. Смешно, но это всего три строчки кода. Может когда-нибудь напишу статью про это.
а сразу сетов на порядок меньше стало.
А статья вам моя про мемкеш смотрю не понравилась, еще один минус появился…
вопрос ко мне? очевидно да.
сторадж сервер — это сервер, на котором хранится контент: фото/видео/аудио/просто файлы
тип файловой системы — это вторично. Скорее всего ext3, но возможно есть что-то более быстрое. Это уже вопросы к админу. конкретную конфигурацию сервера устанавливает админ.
в данном контексте — шардинг про файлы, хотя БД тоже устроена по принципу шардинга. В своих статьях (кажется статья про ленту друзей) в комментах я рассказывал как устоен шардинг БД.
первый nginx — выступает как прокси
второй отдает контент, если вылетает один из стораджей, отдача автоматически проксируется на другой.
Вы единственный, кто заметил этот комментарий. В конце обсуждения я сделал вывод, что публика Хабра еще не готова к теме высоких нагрузок.
в этом случае базу надо денормализовать
дисковое пространство — дешевое
экономия на месте — это экономия на времени отдачи
это простой, процессов, это доп сжираемая память, доп обращение к дисковому пространству в случае свопинга и тд и тп…
Не бери все близко к сердцу,
меня тоже вчера статью про то как я искал где и почему падает мемкеш раскритиковали и наминусовали. А я так, попутно методики поиска еще и раскрыл протокл мемкеш и как его использовать для отладки. Многи не способны увидеть в статье главное.
ну а остальное — оффтоп
Василий, мой опыт значительнее твоего, поверь мне.
Ты, молодец и я тебя за твои стремления и знания уважаю, ты знаешь это.
читай мои комментарии внимательнее, я тебя не ругаю, а даю конструктивную оценку. Ну, грешу, сострил в одном посту, про кол-во использований в проектах PHPDaemon.
как я тебе говорил пару лет назад, тебе надо поработать годик в сильной команде хорошего проета. У тебя есть все потенциальные возможности.
Сомневаешься в чем? что соскочу или что есть обратная дорога?
соскочить трудно по экономическим причинам,
сам понимаешь, сколько получает чел с 10 летним стажем. А на других языках — я буду новичек.
хотя мне было предложение на Сях равноправное РНР, но что-то я не поспешил с ним. Просто сейчас в очень интересном проекте, где кроме знания РНР много чего требуется от меня. Вот, по этому и трудно соскачить.
php-fpm
много место оно не съест, а вот засвопить таблицу cityes он сможет. Ладно, будем надеяться, что у нас сервер достаточно по ресурсам мощный, но вместо одного буфера — будет выделено два — это доп память, потратится время на слияние. микросекунды… но когда речь идет о нагрузках — то боремся и за микросекунды.
про полнотекстовый не было ни сказано ни слова…
любой поиск по полям.
если вопрос про mongodb — то это к автору топика.
я делюсь информацией, как это делается в проектах деци-миллионниках.
шардинг — это распределение данных на разных физических носителях. распределение может быть по разным признакам. В данной теме БД я не затрагивал, а имелось ввиду файловое хранилище. Хочешь обсуждать шардинг БД, wellcome в соседний топик.
контент льется на два стораджа одновременно. Для надежности. А забирается с одного. В случае выхода одного из серверов — он забирается с другого. что тут непонятного!
ну, а теперь предложи схему, как забирать контент, если выйдет файловый-сервер?
да, мемкеш имеет болезнь на запись — это заметно. Боремся расширением, у нас под него отдельный сервер. И еще мы его пропатчили, так что каждое последующее чтение прлонгирует жизнь элемента кеша на тоже время. Смешно, но это всего три строчки кода. Может когда-нибудь напишу статью про это.
а сразу сетов на порядок меньше стало.
А статья вам моя про мемкеш смотрю не понравилась, еще один минус появился…
сторадж сервер — это сервер, на котором хранится контент: фото/видео/аудио/просто файлы
тип файловой системы — это вторично. Скорее всего ext3, но возможно есть что-то более быстрое. Это уже вопросы к админу. конкретную конфигурацию сервера устанавливает админ.
в данном контексте — шардинг про файлы, хотя БД тоже устроена по принципу шардинга. В своих статьях (кажется статья про ленту друзей) в комментах я рассказывал как устоен шардинг БД.
первый nginx — выступает как прокси
второй отдает контент, если вылетает один из стораджей, отдача автоматически проксируется на другой.
Вы единственный, кто заметил этот комментарий. В конце обсуждения я сделал вывод, что публика Хабра еще не готова к теме высоких нагрузок.
дисковое пространство — дешевое
экономия на месте — это экономия на времени отдачи
это простой, процессов, это доп сжираемая память, доп обращение к дисковому пространству в случае свопинга и тд и тп…
бессмысленные религиозные войны…
еще не хватало взять наболевшую тему Win против *nix
спрос на тему есть, открытой информации мало. Кто может ее написать — сильно занят. Вот и появляется куча шарлотанских статей.
Начинаешь раскрывать профф. секреты высоких нагрузок- тебя минусуют. Не готова публика к теме Высоких нагрузок, не готова.
«Анализ программного кода на примерах OpenSource»
Не бери все близко к сердцу,
меня тоже вчера статью про то как я искал где и почему падает мемкеш раскритиковали и наминусовали. А я так, попутно методики поиска еще и раскрыл протокл мемкеш и как его использовать для отладки. Многи не способны увидеть в статье главное.
ну а остальное — оффтоп
У тебя одни успехи, у меня другие
У тебя одни интересы, у меня другие.
это несоизмеримо
Ты, молодец и я тебя за твои стремления и знания уважаю, ты знаешь это.
читай мои комментарии внимательнее, я тебя не ругаю, а даю конструктивную оценку. Ну, грешу, сострил в одном посту, про кол-во использований в проектах PHPDaemon.
как я тебе говорил пару лет назад, тебе надо поработать годик в сильной команде хорошего проета. У тебя есть все потенциальные возможности.
соскочить трудно по экономическим причинам,
сам понимаешь, сколько получает чел с 10 летним стажем. А на других языках — я буду новичек.
хотя мне было предложение на Сях равноправное РНР, но что-то я не поспешил с ним. Просто сейчас в очень интересном проекте, где кроме знания РНР много чего требуется от меня. Вот, по этому и трудно соскачить.
лично я могу публиковаться и в журналах, не проблема.
у меня есть пять публикаций, где-то раз в год по одной (кроме этого года)
здесь как-то проще, вылизывать статьи не надо,
да и можно писать полу-статьи, т.е. укороченные статьи в свободном стиле.
но для его возраста — это вполне отличные результаты