Здравствуйте, DarkGray, Вы писали:
DG>в каких задачах необходимо оперировать в каждый момент времени с таким кол-вом item-ов?
Ну.. это были выкладки для миллиарда штук, что есть перебор. Бери на несколько порядков меньше, но и требования идут не секундные, а мили и микросекундные. И еще нужна предсказуемость... А GC непредсказуем.
DG>я не спрашивал "какие инструменты не подходят для этих задач?", я спрашивал "какие это задачи?"
А с чего ты взял что должны быть какие-то особенные задачи?
Банки, сотовые операторы, крупные ретейлеры, система здравоохраниния и любые организации с массовым обслуживанием населения легко накапливают такие объемы. Задачи — обычные, просто пользователей много, данных много, обращений много
DG>>я не спрашивал "какие инструменты не подходят для этих задач?", я спрашивал "какие это задачи?" R>А с чего ты взял что должны быть какие-то особенные задачи?
потому что миллиард — это очень много. и столько информации одномоментно никогда не используется
R>Банки, сотовые операторы, крупные ретейлеры, система здравоохраниния и любые организации с массовым обслуживанием населения легко накапливают такие объемы.
все эти штуки имеют максимум тысячу одновременных пользователей.
и это означает что необходимо держать в памяти миллион item-ов на каждого пользователя, чтобы бы был миллиард.
но в этих системах нет столько одномоментной информации на каждого пользователя.
R> легко накапливают такие объемы.
тогда это архив, и его не надо держать в памяти
R> Задачи — обычные, просто пользователей много, данных много, обращений много
много это сколько? тысяча обращений в секунду? данных много — это сколько? отдача 50кб html-я на каждый запрос?
DG>потому что миллиард — это очень много. и столько информации одномоментно никогда не используется
если взять по 100байт на айтем то млрд это всего лишь 100гб — обычный рядовой сервер
миллиард это даже не много и уж тем более не очень много — это средне , много данных — это имхо когда активная часть в принципе в оперативку влезть не может
DG>все эти штуки имеют максимум тысячу одновременных пользователей.
оч сильно зависит от задач, прямо сейчас у коллег несколько сот одновременных пользователей, и это относительно мелкий банк, у сбера например на 2 порядка больше сотрудников DG>и это означает что необходимо держать в памяти миллион item-ов на каждого пользователя, чтобы бы был миллиард.
опять же зависит от задач. 5 аналитиков легко нагружают сервер до красного свечения
DG>тогда это архив, и его не надо держать в памяти
да, неактивная часть конечно хранится в архиве
да, если задача поддается распхиванию в кубы
а если нет? дисковая подсистема даст в лучшем случае 1гб\сек, а если данных 200гб? горизонтальное секционирование — дорого
R>> Задачи — обычные, просто пользователей много, данных много, обращений много DG>много это сколько? тысяча обращений в секунду? данных много — это сколько? отдача 50кб html-я на каждый запрос?
я работал с разной нагрузкой, была олтп с требованием <50мс отклик и ~10млн данных, была DSS ~1млрд и 10сек отклик. Много в моем понимании — когда на каждый айтем остается ~1000тиков процессора
R>а если нет? дисковая подсистема даст в лучшем случае 1гб\сек, а если данных 200гб? горизонтальное секционирование — дорого
значит необходимо разделить задачу на две: memory db и все остальное.
в первом gc не будет, а во втором будет.
и linkedin, facebook так обычно и делают. под первое пишется какая-то своя memory-базка, а под второе используется скрипт с gc.
для .net и java-ы принцип остается тот же: долговременный массив отделяется от всей остальной программы, может даже выносится в unmanaged-память, а остальные 80% кода живут вместе с gc
R> да, если задача поддается распхиванию в кубы
какая задача не запихивается в куб? или его аналог?
R> я работал с разной нагрузкой, была олтп с требованием <50мс отклик и ~10млн данных
и при этом каждый пользователь на экран получал 10млн данных на каждый запрос?
или все таки каждый пользователь получал свои 1000 данных на каждый запрос?
и на каких это задачах чтобы вернуть 1000 данных требуется каждый раз проанализировать 10млн. данных?
Здравствуйте, DarkGray, Вы писали:
R>>а если нет? дисковая подсистема даст в лучшем случае 1гб\сек, а если данных 200гб? горизонтальное секционирование — дорого
DG>значит необходимо разделить задачу на две: memory db и все остальное. DG>в первом gc не будет, а во втором будет. DG>и linkedin, facebook так обычно и делают. под первое пишется какая-то своя memory-базка, а под второе используется скрипт с gc. DG>для .net и java-ы принцип остается тот же: долговременный массив отделяется от всей остальной программы, может даже выносится в unmanaged-память, а остальные 80% кода живут вместе с gc
гц нам не мешает, разговор был про случаи когда джит мсовский не дает примлемого перфоманса. непонятно зачем ты все это сюда приплел.
R>> да, если задача поддается распхиванию в кубы DG>какая задача не запихивается в куб? или его аналог?
есть 10 фактов и 100 измерений, аналитик может выбрать группировку(пусть не более 5) и ограничения(не более 10) по любой комбинации. Считать что каждое измерение в среднем содержит 50тыс значений
DG>и при этом каждый пользователь на экран получал 10млн данных на каждый запрос?
пользователь получал _результаты обработки_ 10млн айтемов, для его специфических нужд
DG>и на каких это задачах чтобы вернуть 1000 данных требуется каждый раз проанализировать 10млн. данных?
в моем случае — что-то вроде FTS по пачке связанных FK гридов
Я тоже не понимаю зачем их тестировать ВСЕГДА? Ну вот есть модуль А, который в процессе работы сожрал левые данные от модуля Б и скончался. Вы считаете, что виноват модуль А. При моем подходе вся вина на модуле Б, который не выдержал контракт модуля А. Не выдержал вследствие ошибки в модуле Б или же вследствие того, что модуль Б аналогично получил неверные данные от модуля С (и далее — транзитивно). В итоге источником ошибок окажется некий модуль Х, который либо неверно обслуживает свой контракт, и ошибки в данном модуле должны выявляться тестами на "правильные" сценарии, либо же он становится жертвой внешнего мира, и в этом случае помогут тесты на негативный сценарий. Но заметьте, эти тесты нужны требуются только для модуля Х, работающего с дикой природой. В итоге на практике приходим к тому, о чем говорил ганьюстас, — тестирование неправильных сценариев всегда и везде мягко говоря неразумно, а если верить Мейеру, так еще и вредно.
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>тестирование неправильных сценариев всегда и везде мягко говоря неразумно, а если верить Мейеру, так еще и вредно.
это мягко говоря неточно.
в реальном мире существуют также еще враждебные агенты (вирусы, хакеры, спам и т.д.), и если локальное ПО еще может как-то эти угрозы игнорировать, то распределенное ПО (в том числе сайты) эти угрозы игнорировать не могут.
с учетом этих угроз уточненая формулировка вышеуказанной рекомендации будет следующая:
нет необходимости тестировать неправильные сценарии для выяснения какие именно ошибки там сыпятся; и такое подробное тестирование неправильных сценариев вредно с точки зрения экономии ресурсов, но в тоже время необходимо тестировать (а еще лучше гарантировать) неправильные сценарии на два аспекта: в неправильных сценариях не должен происходить подрыв безопасности, и в неправильных сценариях не должны происходить потери и искажения данных.
С точки зрения разработки еще желательно тестировать, что при неправильных сценариях ошибка проявляется там, где возникла; и не происходит искажение симптоматики.
Все эти аспекты экономичнее гарантировать с помощью архитектуры или используемых инструментов, чем тестировать.
например, использование managed-среды резко уменьшает вероятности наступления в неправильных сценариях всех трех аспектов: подрыв безопасности, потеря или искажение данных, появление разрыва между местом возникновения проблемы и местом ее проявления.
LP>>тестирование неправильных сценариев всегда и везде мягко говоря неразумно, а если верить Мейеру, так еще и вредно.
DG>это мягко говоря неточно. DG>в реальном мире существуют также еще враждебные агенты (вирусы, хакеры, спам и т.д.), и если локальное ПО еще может как-то эти угрозы игнорировать, то распределенное ПО (в том числе сайты) эти угрозы игнорировать не могут.
Я ведь не говорю, что нужно их игнорировать, в моем сообщении написано, что на предмет нарушения контракта нужно проверять только функциональность, которая торчит наружу. Если вернуться к моему сообщению, то нужно тестировать модуль Х на предмет данных угроз. Модуль Х мало того, что должен корректно и безопасно интерпретировать свои входные данные (из дикой природы), он должен работать корректным и безопасным образом с остальными подсистемами, а оные подсистемы должны быть рассчитаны исключительно на работу с правильными данными. Соблюдение контракта некоего модуля должен обеспечивать клиентский код, а не сам модуль. Если для каждого микромодуля проверять возможные случаи нарушения его контрактов, есть риск захлебнуться в унитазе, не доведя работу и до половины.
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>оные подсистемы должны быть рассчитаны исключительно на работу с правильными данными. Соблюдение контракта некоего модуля должен обеспечивать клиентский код, а не сам модуль.
неверно. такая система имеет малый запас прочности, и быстро дохнет при малейшей реальной угрозе (например, как только найдена хоть какая-то уязвимость в клиентском коде, или каким-то образом удалось закинуть троян внутрь системы).
в идеальной, с точки зрения надежности, системе — каждый модуль обязан обеспечивать устойчивость к ошибкам и нападению, в реальной системе — это будет баланс между производительностью и устойчивостью.
LP>>оные подсистемы должны быть рассчитаны исключительно на работу с правильными данными. Соблюдение контракта некоего модуля должен обеспечивать клиентский код, а не сам модуль.
DG>неверно. такая система имеет малый запас прочности, и быстро дохнет при малейшей реальной угрозе (например, как только найдена хоть какая-то уязвимость в клиентском коде, или каким-то образом удалось закинуть троян внутрь системы). DG>в идеальной, с точки зрения надежности, системе — каждый модуль обязан обеспечивать устойчивость к ошибкам и нападению, в реальной системе — это будет баланс между производительностью и устойчивостью.
Клиентский код == потребитель контракта некоего модуля, не обязательно клиент.
Насчет остального — один из отцов ООП Бертран Мейер с тобой не согласен. И тоже ))
Социализм — это власть трудящихся и централизованная плановая экономика.
LP>>Клиентский код == потребитель контракта некоего модуля, не обязательно клиент. DG>вышенаписанное исходило из этого же утверждения. LP>>Насчет остального — один из отцов ООП Бертран Мейер с тобой не согласен. И тоже )) DG>проблема в том, что в быстро меняющемся мире — авторитеты бывают правы очень короткое время (конечно, если не пересматривают свою позицию)
Насколько мне известно, все современные попытки создать безопасную среду выполнения крутятся все вокруг той же идеи — автоматическая гарантия выполнения клиентом контракта.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, gandjustas, Вы писали: ГВ>>>Ты их по скорости сравнивал? G>>Не-а, для моих задач скорости достаточно. Если будет недостаточно, то я могу быстро параллельно запустить расчет. V>Не можешь, т.к. требования, наример, десяток тыщ запросов в секунду. Твои действия?
Че уж там давай сразу мильярд.
Социализм — это власть трудящихся и централизованная плановая экономика.
, много данных — это имхо когда активная часть в принципе в оперативку влезть не может
Ну так и миллион — это очень много. Даже тысяча — тоже очень много. 
