А как насчет «отличный алгоритмист и отличный кодер» в одном флаконе? Я лично знаю таких людей и производительность одного (!) такого человека не возможно сравнить с командой из 50 средних прогаммистов. Потому, что то что напишут они, команда из 50 обычных разработчиков не напишет никогда.
Ок. Поясняю. Твиттер нанимает программиста. Ему дают задачку на программирование. Задачка хорошая. Красивая. Решение предлагается не правильное. Человек не нанимается. Что не так? Нет у твиттера разделения труда на классы программистов. Все должны мочь делать все.
Не знаю как насчет опыта всего человечества, но мой личный опыт мне говорит, что чем меньше людей которые не умеют программировать и пишут хорошие алгоритмы трогают код, тем лучше он в результате оказывается.
В твиттере считают, что реализовывать идею лучше доверить автору этой идеи. В этом если подумать есть смысл. Иногда реализация идеи важнее самой идеи и в процессе реализации могут возникать очень сложные проблемы требующие опять же не стандартных подходов. Если отдавать такую реализацию людям которые умеют только кодить по шаблонам программирования и код лесенкой оформлять, то лучше даже и не браться. Программирование, как известно это не стрижка газонов, и если ты хочешь толкать индустрию и возможности железа туда где еще никто не был, то мелочей которые можно доверить кому-то другому почти не остается.
Почему это не ответ? Если ты хочешь чтобы твоя компания выигрывала у конкурентов, тебе надо делать то, что никто больше не делает, а для этого тебе нужны люди, которые мыслят не стандартно и умют эти мысли вополщать в дело.
Понятно. Спасибо. У нас примерно 360 миллиардов документов сейчас. Плюс индексы к ним. Нагрузки в среднем 5-6К в секунду. Пик нагрузки по вечерам 80-100К запросов в секунду. Вот сейчас думаем как поднять пиковвую произвождительность без катастрофических расходов :)
Это просто идеология компании такая. Они к разработчикам относятся, как к ключевым людям в компании. Они ждут от разработчиков идей, которые помогут развивать продукт и бизнес компании. Делать то, что раньше никто не делал. Это не та компания, где разработчик приходит на работу, а у него на столе талмуд от Product Manager с подробным описанием следующей фичи, а разработчику надо только аккуратно закодить, то что требуется. Это просто разные подходы к должности.
Шикарно живете :) Диски по 100Мб/сек и полки на несколько десятков дисков на каждом сервере. Я в более общем случае рассуждал, когда диски медленные и сервера слабенькие могут быть, а производительность все равно нужна высокая. Плюс иногда бывает нужен не весь файл, а его кусочек. (Как в нашем случае). Тогда основная проблема это время disk seek, не скорость передачи данных. В этом случае выгоднее иметь файл разбросаным по серверам.
Кстати очень много файлов это сколько? Порядок какой?
Спасибо!
Знаний с цифрами у меня тлоько про наш конкретный слуйчай, как он к вашему относится не очень понятно. В общем Вы все правильно написали про плюсы и минусы. Еще только про одну вещь я бы все таки подумал общая пропускная способность системы. Если доступ идет одновременно к ограниченному количеству файлов по сравнению с общим объемом хранимых данных, то получается выгоднее файлы разбивать на куски и разбрасывать их по серверам. Типа торрента чтобы получалось. Тогда получается максимально задействовать все головки дискови повысить общую пропускную способность хранилища.
Мне кажется логичнее было бы хранить данные кусками фиксированного размера. Большие файлы дробить, а маленькие объединять. В вашей текущей архитектуре будет вам будет тяжело рахбираться с миллиардами маленьких файлов и большими файлами в несколько террабайт. Куски фиксированного размера позволят эффективнее использовать дисковое пространство на сервере и повысят производительность (TPS) при доступе к большим файлам.
Что делаете с нагрузкой на базу хешей файлов? Насколько я понимаю такая база должна быть централизованной. Какие нагрузки (запрос/сек) реально вы испытывали?
Спасибо!
Кстати очень много файлов это сколько? Порядок какой?
Спасибо!
Спасибо!