а) Но ведь если хранилище основано на хранении данных на жестком диске, то оно скорость доступа изначально меньше, нежели у кеша, держащего данные в оперативной памяти.
б) Я этого не утверждал, вероятно вы меня не так поняли, или же я не так выразился. Как мне кажется, стоит вначале отправить данные в хранилище, но и так же спровоцировать их обновление в кеше (повторным считыванием из хранилища, или же прямой записью в кеш)
Да, вы несомненно правы, что много в чем мои представления о том, как лучше или же хуже реализовывать что-то в рамках высоконагруженного сервиса весьма далеки от реальности. Логику работы можно продумать как с учетом использования только SQL систем, так и с учетом кешей, с учетом nosql и всего остального — но мой опыт не позволяет дать на этот мой собственный вопрос более-менее конкретный ответ, потому я и стараюсь узнать больше про опыт других :) Надеюсь вы не сочтете неправильным то, что я решил попытаться узнать чужой опыт, прежде чем с головой бросится в создание архитектуры и кодописание!
«как балансировщик будет распределять нагрузку» — я то понимаю что магии не бывает, потому и был задан такой вопрос. Много где было написано — вот, балансирует, вот, на самый не нагруженный сервер. А каким образом у балансировщика обратная связь от серверов — я так и не понял, и не нашел где об этом почитать (возможно не так/не там искал).
Относительно Апача — я ведь не говорил что он и только он. Вероятно я не точно выразился, и стоило на писать «Web-сервер, способный отдавать динамический контент».
Про легкость поддержки большого парка — об этом я думал, уж поверьте, и анализировал тоже не 5 минут эту область. Мой вывод свелся к тому что ошибка на любой из нод вероятнее всего должна привести к автоматизированному разворачиванию на ней «свежей системы», уже сконфигурированой — но через обычную установку. Но сомнений в работоспособности этой структуры тоже много, вот хочу проверить, но время никак не подвернется.
По базу данных на графах — вот видите, сколь ценен ваш ответ! Я также не слышал, но предположительно я просто могу быть не в курсе. А вы не слышали — это уже говорит что вариант я выбрал 99.9% неправильный.
Почему я предполагал/предполагаю использовать отдельно базу для хранения объектов, а отдельно связей между ними (некое подобие дерева) — потому что на данном этапе анализа мне кажется что связи между объектами будут востребованы чаще. Хотя на самом деле тут еще анализировать, анализировать и еще раз анализировать. Хотя эффект от этого топика также не стоит недооценивать :) За что и спасибо )
Благодарю как за советы, так и за отзывы о моей весьма малой компетенции в вопросе поднятом в топике, они очень и очень ценны. Хотя в кое-чем я все же с вами не согласен, поскольку не только задача влияет на выбор технологии, но и наоборот, с развитием решения этой задачи. Список из первичного поста тоже ведь не с потолка был взят, и вопросы сводились «Вот то что мне пришло в голову. Сильно ли я дурак с такой мыслью?».
Мне бы очень хотелось услышать о более приземленной практике использования nosql (я прочитал в вашем профиле что вы используете и nosql также). И ни в коей мере я не прошу решать за бесплатно мои задачи, как и вообще решать мои задачи, иначе бы я описал все гораздо более в полной мере с предполагаемыми нагрузками, задачами и предположительными проблемами. К примеру вопрос о базе для хранения связей. Вопрос по этому пункту вероятно лучше сформулировать так: «Вы использовали? Какую? Для решения чего? Обо что шишки набили?». Такого вида вопросы можно ставить почти к всем пунктам что я описал в самом начале. Как вы сами понимаете, это позволит мне откинуть совершенно идиотские свои же выводы, или же проанализировать ту или иную область системы более детально. Т.е. мне интересен опыт других в подобной тематике, ибо я не хочу набивать уже многими пройденные шишки, поскольку это будет достаточно пустая трата времени.
Не щупали те которые распределенные? Типа BigTable? Да, про Mongo и я читал что горизонтального масштабирования там нету нормального, только вертикальное.
Мне кажется мы о разных вещах говорим. memcached != nosql насколько я понимаю. А redis скорее не memcached а memcacheDB. Т.е. я понимаю под nosql все-таки базу которая хранит данные на дисках, а не в оперативке. А за/перед nosql стоит уже memcached который это дело кеширует. Или я в чем-то ошибаюсь?
Ну как всегда, решение одной проблемы приносит новые, в данном случае инвалидация кеша! Спасибо за подсказки! Не знаете кто бы мог рассказать по топику о практике использования nosql и шишек связанных с этим?
К счастью я так не думаю и не фантазирую на тему мирового господства достаточно узко-направленного сервиса :) Из вашего рассказа для себя в технологическом плане вынес заметку о кеше — думать о нем желательно сразу. Конечно же, не стоит все переусложнять, но все-таки keep-in-mind стоит во время разработки. Под статикой понимается оформление страниц и то что так или иначе с этим связано (картинки, таблицы стилей)? Или же в добавок к этом еще и статический контент, который добавляется динамически (простите за такое изречение)? Я имею ввиду к примеру медиа-контент пользователя отдается на прямую в виде файлов. При этом получается что по прямой ссылке на контент он доступен в обход тех или иных ACL.
Спасибо за пояснения, в этом понимании терминов действительно все 3 невозможны одновременно. Можно ли понимать под «часть серверов может хранить устаревшие » устаревание кеша? Т.е. если имеется хранилище (медленное) данных, где они должны быть консистентны по умолчанию, то при изменении данных в нем (запись), оно не будет мгновенно реплицировано сквозь кеши одного и более уровней, и как результат кто-то не увидит сразу какие-то изменения. И, соответственно, если кеши не в каком-то смысле managed, при большом ttl получим невообразимое безобразие. Я так полагаю что это пытаются (и может даже успешно решают), но как? При любой записи делать не-блокирующий броадкаст по всем кешам? Делать маленький ttl?
Уточняя самого себя. В вопросах было высказано предположение использовать key-value базы для хранения объектов и какой-то базы для хранения графа связей этих объектов. Это ведь повлияет довольно сильно на архитектуру взаимодействия в системе. Но к примеру в статье про архитектуру facebook было сказано что они используют MySQL для хранения пар key-value что мне кажется не логичным (я не спорю, что для них это логично, просто подана информация так, что я не вижу в чем суть такового использования).
Если я вас правильно понял, то под высокой доступностью имеется ввиду отказоустойчивость системы (т.е. минимальность времени простоя), под консистентностью данных — их целостность в общем виде, что кроме прочего обеспечивается резервированием этих самых данных. Если я вас правильно понял, то я не совсем себе могу представить почему производительность (если имеется ввиду количество обработанных запросов пользователей за единицу времени) не может быть совмещена с высокой доступностью. Скорее эти 2 понятия не могут быть совмещены с консистентностью данных, которые могут быть утеряны при выходе из строя выпадением ноды (ухудшение показателя надежности, и как следствие доступности), или же которые по архитектуре держатся в оперативной памяти и не были записаны на диск (обратный подход означает потерю производительности).
Для того чтобы начать с архитектуры приложения я хочу понять что и как я могу использовать, что и отображено в некоторых вопросах-уточнениях топика. Потому как я могу по незнанию теоретической базы доступных технологий могу такого «наархитектировать», что потом не реализую. Если у вас есть опыт работы в данной области, расскажите о том что вы использовали и как (если конечно не является секретом NDA и т.д.), я буду очень признателен!
Это успокаивает мои нервы относительно «Что делать»! Поделитесь знаниями о том что я писал про предположения по технологиям? Жажда знаний и все такое :)
Есть еще одна важная деталь, которую я забыл упомянуть. Сервисов несколько, но они используют много общего контента (т.е. они как бы отдельные, но интегрированные). Впрочем, спасибо за ценный совет, несомненно это повлияет на скорость разработки. Но все-таки теорию описанную в самом вопросе, хотелось бы прояснить для себя. Потому вопрос все еще активен :)
Ох, сложно сказать, поскольку идея самого проекта не проверялась на социуме :) Потому это будет больше в попугаях, как люди воспримут сервис. Как гмейл (проверил и ушел) или как хабр (читаю-коментю-читаю-коментю-...). Через год предполагаем по самым оптимистичным размышлениям не более 25к пользователей. Про просмотры говорить рано — причина описана выше.
Благодарю, почитаю обязательно! Нет, пока что не вбухиваю, только думаю и размышляю об этом, потому это все-таки не столько «преждевременная оптимизация», сколько то, что стоит не забывать что потом это возможно будет необходимость это оптимизировать. Зная это, а так же вероятные пути решения, легче учесть это сейчас и не применять методов которые сделают в дальнейшем оптимизацию еще сложнее. К примеру, если я сейчас сделаю все на одной базе, без кеширования и т.п., или попросту дорихтую какую-то CMS под свои нужды, мое имхо, я допущу огромную ошибку, поскольку потом это 100% выбросится полностью. Но тем не менее, безмерно благодарю за подсказки.
б) Я этого не утверждал, вероятно вы меня не так поняли, или же я не так выразился. Как мне кажется, стоит вначале отправить данные в хранилище, но и так же спровоцировать их обновление в кеше (повторным считыванием из хранилища, или же прямой записью в кеш)
Да, вы несомненно правы, что много в чем мои представления о том, как лучше или же хуже реализовывать что-то в рамках высоконагруженного сервиса весьма далеки от реальности. Логику работы можно продумать как с учетом использования только SQL систем, так и с учетом кешей, с учетом nosql и всего остального — но мой опыт не позволяет дать на этот мой собственный вопрос более-менее конкретный ответ, потому я и стараюсь узнать больше про опыт других :) Надеюсь вы не сочтете неправильным то, что я решил попытаться узнать чужой опыт, прежде чем с головой бросится в создание архитектуры и кодописание!