>Кстати, слышал много баек про хайринг процесс в гугл, что может длиться до 9 месяцев.
это байка из ЖЖ обошла весь рунет, как наш аспирант, стажировавшийся в Японии, устраивался работать в Гуугль, прошел три или четыре собеседования, на одно из которых летал в США, но так к ним и не попал. Вся эпопея длилась полтора года.
знаешь, я был на стажировке в IISA (Австирия)
и вспоминаю эти дни с большим удовольствием.
Было трудно, но интересно. Чему-то я научился, какую-то пользу принес Институту.
Меня не взяли работать, но не беда, у каждого свой путь…
не всегда устроиться просто без высшего образования. Очень часто на форумах поднимали вопрос а нужно-ли оно Высшее образование. Да — нужно, если не хочешь быть всю жизнь говнокодером в мелкой компании. У меня два примера, когда у людей пообламывалась хорошая перспектива из-за того, что в свое время побросали институты.
а мне кажется шансы одинаковые. Но факт стажировки в любом случае отличный старт в карьере. Был бы студентом, подал бы документы на стажировку в школу алгоритмов и структур данных Microsoft.
у нас дружба шла отдельной таблицой, которая шардится по user_id. таким образом — был построен только первый круг. Построение второго круга оказалась довольно-таки трудоемкая процедура, по этому решили вынести всех «друзей» в центральное хранилище.
но, с другой стороны, всякому будет интересно, через каких друзей он связан с Дмитрием Котеровым.
а как дела обстят с шардингом? или всю «дружбу» сливают в одну центральную БД.
у меня почему такая архитектура: потому что все профили пользователей разбиты по мускульным шардам, а всю дружбу решили загнать в монго.
это время затраченное на поиск за 5-м-6-м кругом,
конечно смешно искать в цепочке во втором круге.
Несомненно, если A и B в первом-втором круге друг у друга — цепочка получается мгновенно.
весь поик осуществляется онлайн, есть место для оптимизации кода. На тестовом сервере цепочка получается почти мгновенно.
сколько займет время пересечения?
один такой умник (архитектор tradebox), чтоб не гонять данные по сети, решил большую часть логики впихнуть в БД в ввиде хранимых процедур. В результате когда вышли на реальную нагрузку база просела, мощный сервер просто не стал справляться.
так что надо соизмерять что можно делать при нагрузках, а что нельзя.
ну я про А ты про Бэ…
можно и в редиске, но в том же формате, что и в memcachedb
по этому выигрыша абсолютно ни какого.
списки редиса здесь никаким боком не засунешь, а если и засунешь, то только огребешь лишнюю головную боль и тормоза.
замечу что мемкеш и memcachedb — это все же разные системы хранения данных.
по вопросу выбора языка:
выбран C++, так как скриптовые языки требуют много памяти под выделяемые хешмассивы.
2-круг есть пользователи более 400 друзей, третий от 1200 друзей. Хотелось бы все вычисления делать быстро в онлайн.
приложение реализовано как fcgi модуль, проксируется через nginx
на Хабре очень любят придраться к опикам.
сасибо за замечания.
мне было 30, когда я был на стажировке в Австрии
а кому-то из наших 32.
это байка из ЖЖ обошла весь рунет, как наш аспирант, стажировавшийся в Японии, устраивался работать в Гуугль, прошел три или четыре собеседования, на одно из которых летал в США, но так к ним и не попал. Вся эпопея длилась полтора года.
и вспоминаю эти дни с большим удовольствием.
Было трудно, но интересно. Чему-то я научился, какую-то пользу принес Институту.
Меня не взяли работать, но не беда, у каждого свой путь…
но, с другой стороны, всякому будет интересно, через каких друзей он связан с Дмитрием Котеровым.
есть у кого проконсультироваться!
так вы там на постгресе делаете пересечения?
а как дела обстят с шардингом? или всю «дружбу» сливают в одну центральную БД.
у меня почему такая архитектура: потому что все профили пользователей разбиты по мускульным шардам, а всю дружбу решили загнать в монго.
конечно смешно искать в цепочке во втором круге.
Несомненно, если A и B в первом-втором круге друг у друга — цепочка получается мгновенно.
весь поик осуществляется онлайн, есть место для оптимизации кода. На тестовом сервере цепочка получается почти мгновенно.
но, очевидно, с высоконагруженными системами ты не работал.
один такой умник (архитектор tradebox), чтоб не гонять данные по сети, решил большую часть логики впихнуть в БД в ввиде хранимых процедур. В результате когда вышли на реальную нагрузку база просела, мощный сервер просто не стал справляться.
так что надо соизмерять что можно делать при нагрузках, а что нельзя.
если я где-то не прав, то поправлю
если Вы представите мне структура данных на редисе.
а самым предметным — если сделать тесты
согл: практически любое key-value хранилище справилось не хуже бы
выбор за MongoDB:
— масштабируемость
— возможность репликации
— планируем использовать для других данных
сколько приблизительно запросов надо сделать на создание цепочки?
есть задачи в которых мускуль выигрывает — это бесспорно. В данной — мускул проигрывает.
можно и в редиске, но в том же формате, что и в memcachedb
по этому выигрыша абсолютно ни какого.
списки редиса здесь никаким боком не засунешь, а если и засунешь, то только огребешь лишнюю головную боль и тормоза.
замечу что мемкеш и memcachedb — это все же разные системы хранения данных.
выбран C++, так как скриптовые языки требуют много памяти под выделяемые хешмассивы.
2-круг есть пользователи более 400 друзей, третий от 1200 друзей. Хотелось бы все вычисления делать быстро в онлайн.
приложение реализовано как fcgi модуль, проксируется через nginx