А GC знает только о живых объектах, все остальные он считает мусором, поэтому если со стека ссылки на циклическую структуру не будет (ну и еще несколько условий в зависимости от типа GC, платформы и т.д.), то она автоматически будет считаться мусором.
Честно говоря, я никогда не работал с ElasticSearch, поэтому не знаю насколько мои вопросы корректны, но всё же есть пару вопросов:
1) у вас шарды дифференцированы по типу индекса? Например: эти 20 шардов для FB, это 30 для Twitter и т.д.? Мне кажется, что если их так разделить, то можно настроить роутинг внутри группы шардов.
2) может вообще стоить разделить индексацию из разных типов источников данных по разным кластерам ElasticSearch, тогда вы во-первых сможете делать параллельные запросы по одному и тому же юзеру, но по разным источникам данных, а во вторых роутинг внутри каждого кластера сократит время запроса. Тогда получится, что суммарное время выполнения запроса будет не больше, чем самый долгий запрос по одному источнику (но и он будет не такой уж и долгий за счет того, что путь к шарде будет известен заранее)
На уровне java кластера транзакционность есть, но на уровень PHP я её еще не пробросил. Более того, как мне кажется без реализованного write-behind транзакционность не сильно нужна, поэтому подумаю над ней в следующем релизе, т.к., судя по результатам опроса, эта фича пока востребованнее всех.
Mongo хранит JSON (который является строкой), а грид хранит ваши объекты с учетом их типов.
Плюс к этому сам грид хранит данные только в памяти, запись их в постоянное хранилище (БД, файловая система и т.д.) можно настроить самостоятельно, но этим хранилища не являются частью кластера, а Mongo хранит всё на диске и сама решает, какие из имеющихся данных держать в памяти, то есть здесь разная концепция использования.
Правильнее рассматривать гриды как «умный кеш с возможностью обработки данных и записи их в БД», а не как «быстрая БД».
На тему теорий заговоров по каждому поводу я с вами соглашусь (это очевидный бред), но ваш пример про Сашу и Катю — это ложная аналогия, потому что она про личные отношения.
Корректнее было бы, если бы вы привели пример про то, что какой-нибудь крупной компании выгодно сотрудничать с компанией А, но она почему-то решила сотрудничать с компанией Б в ущерб своей выгоде. Согласитесь, это звучит странно? Крупная коммерческая струтура не может действовать в терминах «честно/нечестно», «правильно/неправильно», а только в терминах «выгодно/невыгодно» (если размер штрафа за нарушение закона будет меньше получаемой прибыли за счет этого нарушения, то компания будет нарушать закон).
Так как практически во всех странах существуют антимонопольные органы, то это означает, что заговоры компаний на местном рынке — это реальность. Тогда почему не должно быть заговоров на глобальном рынке? Более того, я уверен, что они там есть.
Если принять, что экономические причины — это основа всех процессов в мире, то из этого следует, что тот, кто контролирует экономику, контролирует весь мир. Скажите, почему монопольный сговор ведущих финансовых компаний мира является маловероятным? Мне кажется, что они были бы полными идиотами, если бы не воспользовались своими возможностями по контролю основных мировых политических и экономических процессов путем обычного монопольного сговора.
Один бывший коллега уехал в F-Secure (здесь был senior Java, там — не знаю), один коллега — не так давно вернулся из Финки (С++, говорит, что стало скучно), но компанию я не спрашивал.
Мне самому F-Secure предлагали пройти собеседование (я тогда был middle Java). Так что предложения есть, обычно они через кадровые агенства поступают.
Я думаю, что вы читали предыдущую статью, рассказывающую об ограничениях, которые несовместимы с выражением «100% безлимитный», но этот пункт в своей статье оставили.
Можете как-то прояснить безлимитность безлимита?
Использовать рабочее время было бы некорректно, да и опасно, потому что в случае успеха любого вашего проекта у вас могут начаться юридические сложности, поэтому на работе я этим не занимаюсь принципиально.
Дело в том, что я живу около одной из крайних станций метро (СПб, метро пр. Просвещения) и езжу на работу не в час пик, поэтому у меня есть возможность сесть с ноутом и полчаса работать, пока не доеду до станции, на которой мне выходить. Т.е. получается, что я пишу код даже 2 раза в день (полчаса по дороге на работу, полчаса по дороге домой). Несмотря на то, что это не такой уж и простой проект, я не успеваю выпасть из контекста, т.к. не проходит слишком много времени между сессиями написания кода, а перед тем, как зайти в метро, я иду от работы 15 минут пешком (от дома — 10 минут). Это время я трачу на то, чтоб составить себе план работ на ближайшие полчаса.
Именно поэтому я в свое время полностью решил отказаться от машины для поездок на работу (она у меня для поездок в выходные + в будни по семейным делам), а также не пользуюсь транспортом, если можно дойти пешком за 15-20 минут.
Я тоже пришел к такому режиму работы над своим проектом. При этом у меня исчезло такое явление как прокрастинация при работе над длинным проектом, и повысилась продуктивность. Я выделяю всего час в день и совсем не работаю по выходным (время, которое провожу дома, принадлежит только моей семье) и за последние 3 месяца сделал больше, чем за предыдущий год, пытаясь заставить работать себя по ночам.
Надеюсь, что скоро опубликую статью про первую версию своего проекта.
У вас на сайте сказано, что вы не просто бухгалтерская компания, а еще и юридическая + банк + бизнес-ассистент, это заложено в 12 тыс? Или вы будете поэтапно рассказывать про направления своей деятельности и расценки на них?
1) у вас шарды дифференцированы по типу индекса? Например: эти 20 шардов для FB, это 30 для Twitter и т.д.? Мне кажется, что если их так разделить, то можно настроить роутинг внутри группы шардов.
2) может вообще стоить разделить индексацию из разных типов источников данных по разным кластерам ElasticSearch, тогда вы во-первых сможете делать параллельные запросы по одному и тому же юзеру, но по разным источникам данных, а во вторых роутинг внутри каждого кластера сократит время запроса. Тогда получится, что суммарное время выполнения запроса будет не больше, чем самый долгий запрос по одному источнику (но и он будет не такой уж и долгий за счет того, что путь к шарде будет известен заранее)
Это прекрасно.
Плюс к этому сам грид хранит данные только в памяти, запись их в постоянное хранилище (БД, файловая система и т.д.) можно настроить самостоятельно, но этим хранилища не являются частью кластера, а Mongo хранит всё на диске и сама решает, какие из имеющихся данных держать в памяти, то есть здесь разная концепция использования.
Правильнее рассматривать гриды как «умный кеш с возможностью обработки данных и записи их в БД», а не как «быстрая БД».
Корректнее было бы, если бы вы привели пример про то, что какой-нибудь крупной компании выгодно сотрудничать с компанией А, но она почему-то решила сотрудничать с компанией Б в ущерб своей выгоде. Согласитесь, это звучит странно? Крупная коммерческая струтура не может действовать в терминах «честно/нечестно», «правильно/неправильно», а только в терминах «выгодно/невыгодно» (если размер штрафа за нарушение закона будет меньше получаемой прибыли за счет этого нарушения, то компания будет нарушать закон).
Если принять, что экономические причины — это основа всех процессов в мире, то из этого следует, что тот, кто контролирует экономику, контролирует весь мир. Скажите, почему монопольный сговор ведущих финансовых компаний мира является маловероятным? Мне кажется, что они были бы полными идиотами, если бы не воспользовались своими возможностями по контролю основных мировых политических и экономических процессов путем обычного монопольного сговора.
Мне самому F-Secure предлагали пройти собеседование (я тогда был middle Java). Так что предложения есть, обычно они через кадровые агенства поступают.
Я думаю, что вы читали предыдущую статью, рассказывающую об ограничениях, которые несовместимы с выражением «100% безлимитный», но этот пункт в своей статье оставили.
Можете как-то прояснить безлимитность безлимита?
Дело в том, что я живу около одной из крайних станций метро (СПб, метро пр. Просвещения) и езжу на работу не в час пик, поэтому у меня есть возможность сесть с ноутом и полчаса работать, пока не доеду до станции, на которой мне выходить. Т.е. получается, что я пишу код даже 2 раза в день (полчаса по дороге на работу, полчаса по дороге домой). Несмотря на то, что это не такой уж и простой проект, я не успеваю выпасть из контекста, т.к. не проходит слишком много времени между сессиями написания кода, а перед тем, как зайти в метро, я иду от работы 15 минут пешком (от дома — 10 минут). Это время я трачу на то, чтоб составить себе план работ на ближайшие полчаса.
Именно поэтому я в свое время полностью решил отказаться от машины для поездок на работу (она у меня для поездок в выходные + в будни по семейным делам), а также не пользуюсь транспортом, если можно дойти пешком за 15-20 минут.
Надеюсь, что скоро опубликую статью про первую версию своего проекта.