Так и не понял критерия, по которому они давали доступ пару лет назад.
Пользуюсь сервисом с 2011 года, на территории США не был и в личных данных подобной информации не указывал.
Я описывал пример мап-редьюса в принципе.
Ваш пример не описывает что это за строки и как к ним получается доступ, потому что основной посыл в моем предыдущем комментарии про доступ к данным, а не только про их обработку.
А последнее про то, что иногда для конкретных задач маленькие записи выгоднее, ну естественно, кто же спорит? Но…
то чем больше слов в одной записи, тем дольше будет выполняться вся работа.
То, что Вы описали похоже только на оптимизацию работы одной ноды, а где же сам map-reduce? Чем меньше работы у одной ноды, тем больше будет у мастера и наоборот (это только в вашем случае, для моего примера это не играет роли).
Ух ты! Это очень простой и правильный способ!
Но, есть одно «но», результат будет всё же еще зависеть от частоты обновления экрана, а, соответственно, от производителя и его микроконтроллеров монитора.
Я бы предположил, что можно попробовать снять на видео с высоким числом кадров в секунду, думаю, даже на 120 можно уже отловить разницу, если просматривать покадрово.
А вы пробовали использовать Splashtop? На что Вы основываетесь в своем высказывании?
По личному опыту, используя Splashtop, делал хитрость: стационарный комп ощутимо мощнее ноутбука, я на нем запускал всемизвестный командный шутер от первого лица, а играл с ноутбука, сидя в другой комнате (по кабелю, не по wi-fi), я забывал о том, что это Splashtop и игра запущена на другом пк, и на геймплее никак не отражалось.
P.S. Я не знаю как им удалось добиться таких высоких показателей, но факт есть факт.
Передвижение данных тут не при чем. Чтобы с данными что-то сделать, провести какую-то обработку, треубется доступ к этим данным, и доступ к 1млрд записей общим объемом 1ТБ будет занимать больше времени, нежели 1млн того же объема.
Для наглядности могу привести такой
пример абстрактной задачки со смешными цифрами
Есть 10 серверов, общий объем полезных данных ~74ГБ и 10млрд записей равномерно распределенные по этим серверам.
В каждой записи есть 64-битный Integer(т.е. запись занимает 8 байт).
Вам нужно высчитать среднее по всем записям. Каждый юнит в таком случае высчитывает среднее из 1млрд записей, после чего сливаются воедино 10 записей и из них высчитывается среднее.
Теперь возьмем эту же задачу, только данных будет не 10млрд, а 80млрд, и будет не Int64, а Byte(т.е. занимает, не 8 байт, а 1). Теперь при том же общем объеме данных каждый юнит должен высчитать среднее не из 1млрд записей, а из 8млрд записей.
Скажите, пожалуйста, теперь мне удалось объяснить разницу?
Я понял Вашу мысль.
Но, если есть еще в запасе неиспользуемые ядра, которые можно использовать(вы не описали в примере обратное), то почему их не использовать и почему они не были использованы сразу? Сомневаюсь, что это можно отнести к горизонтальному масштабированию, это просто подгонка под свободные ресурсы в разрезе одного сервера. Иначе, исходя из Вашего комментария можно отнести к горизонтальному масштабированию увеличение количества воркеров какого-нибудь гирмана для одной очереди.
И тем не менее это ведь не исключает высказывание olku
Будет ли появляться вредная для зрения усталость глаз после долгого использования Oculus Rift
Одна из замечательных особенностей Oculus Rift, — это то, что он практически не вызывает усталости глаз. Глаза в Oculus Rift устают гораздо меньше, чем от обычных дисплеев или очков виртуальной реальности.
Усталость глаз возникает, когда вы смотрите на монитор и ваши глаза сфокусированы все время на одном и том же расстоянии. В Oculus Rift такого эффекта нет. Ваши глаза будут все время фокусироваться на разных точках: иногда вы будете вглядываться в даль, а иногда смотреть на что-то поближе. Ваши зрачки будет постоянно работать, как в естественной среде, поэтому глаза не устанут и вреда здоровью не будет.
Использую Splashtop постоянно, задержки настолько минимальны, что я их вообще не вижу.
Обычно досматриваем с женой фильмы на планшете в FullHD через Splashtop (когда надоедает сидеть перед экраном за столом), всё идеально гладко.
Абсолютно с Вами согласен.
И еще один момент: нельзя все измерять в байтах-гигабайтах; когда мы говорим о BigData, то это еще и большое количество «записей», и 1ТБ данных из 1млн «записей» будет работать в разы быстрее, нежели этот же 1ТБ из 1 млрд «записей».
У нас термопот стал и для удобства и для экономии. Жена кипятила чайник постоянно, для всего, даже чтобы в кастрюлю воды налить и не ждать, пока на плите вскипит. Таким образом чайник за сутки у нас потреблял больше электроэнергии, нежели термопот, так как если в термопот постоянно доливать, то ему не нужно много энергии с нуля кипятить.
И, да, мы тоже пользуемся отфильтрованной водой, стенки чистые абсолютно, в использовании уже скоро год.
Многоразовая станция для небольших экспериментов, например.
Присоединяюсь к вопросу huze.
UPD: Упс, как же давно, оказывается, я открыл страницу-то. Все ответы уже есть.
Instagram перешел с gearmand на celery.
Мы, кстати, у себя гирман используем очень и очень много где и тоже подумываем переходить, привысоких нагрузках гирман начинает подтупливать, а именно выполняя одну очередь, забивает на другие полностью, и даже приоритеты задач не помогают.
Год назад мы с женой решили сменить чайник на термопот, и, знаете, это счастье!
Вода всегда кипяток, подошел и налил, никаких ожиданий пока вскипит и прочее, только воду доливай и все. Самое смешное, что стОит-то тех же денег, что и чайник нормальный. Советую!
А вы с aviasales.ru никак не связаны? Я на нем часто ищу билеты, и удивила схожесть интерфейсов.
А вот узнать про алгоритмы ценообразования и оптимизации стоимости было бы интересно!
Сам пытался выявить, не получилось, при чем до того не получилось, что пришлось поездом ехать, т.к. на нужный мне день цена взлетела в 3 раза, вместо того, чтобы упасть в полтора (на что я рассчитывал).
Минусы есть везде и всегда, нужно только попытаться их заставить работать на Вас и стать плюсами!
Просто после продолжительного времени работы БД под рельной большой нагрузкой мне сомнительно, что монго сама упала, хотя в Вашей формулировке это звучит именно так. Скорее я поверю, что вылетел сам сервер с битой памятью, развалившемся рейдом или оом-киллер убил монгу, потому что на сервере еще что-то располагалось кроме базы данных.
А вообще проблема, которую мы тут обсуждаем, — это издержки неправильной архитектуры (которая, к сожалению, в некоторых компаниях бывает из-за нежелания руководства выделять финансы на оверхед данных — репликацию).
Пользуюсь сервисом с 2011 года, на территории США не был и в личных данных подобной информации не указывал.
Ваш пример не описывает что это за строки и как к ним получается доступ, потому что основной посыл в моем предыдущем комментарии про доступ к данным, а не только про их обработку.
А последнее про то, что иногда для конкретных задач маленькие записи выгоднее, ну естественно, кто же спорит? Но…
То, что Вы описали похоже только на оптимизацию работы одной ноды, а где же сам map-reduce? Чем меньше работы у одной ноды, тем больше будет у мастера и наоборот (это только в вашем случае, для моего примера это не играет роли).
Но, есть одно «но», результат будет всё же еще зависеть от частоты обновления экрана, а, соответственно, от производителя и его микроконтроллеров монитора.
Я бы предположил, что можно попробовать снять на видео с высоким числом кадров в секунду, думаю, даже на 120 можно уже отловить разницу, если просматривать покадрово.
По личному опыту, используя Splashtop, делал хитрость: стационарный комп ощутимо мощнее ноутбука, я на нем запускал всемизвестный командный шутер от первого лица, а играл с ноутбука, сидя в другой комнате (по кабелю, не по wi-fi), я забывал о том, что это Splashtop и игра запущена на другом пк, и на геймплее никак не отражалось.
P.S. Я не знаю как им удалось добиться таких высоких показателей, но факт есть факт.
Для наглядности могу привести такой
В каждой записи есть 64-битный Integer(т.е. запись занимает 8 байт).
Вам нужно высчитать среднее по всем записям. Каждый юнит в таком случае высчитывает среднее из 1млрд записей, после чего сливаются воедино 10 записей и из них высчитывается среднее.
Теперь возьмем эту же задачу, только данных будет не 10млрд, а 80млрд, и будет не Int64, а Byte(т.е. занимает, не 8 байт, а 1). Теперь при том же общем объеме данных каждый юнит должен высчитать среднее не из 1млрд записей, а из 8млрд записей.
Скажите, пожалуйста, теперь мне удалось объяснить разницу?
Но, если есть еще в запасе неиспользуемые ядра, которые можно использовать(вы не описали в примере обратное), то почему их не использовать и почему они не были использованы сразу? Сомневаюсь, что это можно отнести к горизонтальному масштабированию, это просто подгонка под свободные ресурсы в разрезе одного сервера. Иначе, исходя из Вашего комментария можно отнести к горизонтальному масштабированию увеличение количества воркеров какого-нибудь гирмана для одной очереди.
И тем не менее это ведь не исключает высказывание olku
oculus-rift.ru/faq/:
Обычно досматриваем с женой фильмы на планшете в FullHD через Splashtop (когда надоедает сидеть перед экраном за столом), всё идеально гладко.
И еще один момент: нельзя все измерять в байтах-гигабайтах; когда мы говорим о BigData, то это еще и большое количество «записей», и 1ТБ данных из 1млн «записей» будет работать в разы быстрее, нежели этот же 1ТБ из 1 млрд «записей».
И, да, мы тоже пользуемся отфильтрованной водой, стенки чистые абсолютно, в использовании уже скоро год.
Присоединяюсь к вопросу huze.
UPD: Упс, как же давно, оказывается, я открыл страницу-то. Все ответы уже есть.
UPD: После перезагрузки страницы стал правильно отображаться
P.S. На первом фото отдаленно напоминает
Мы, кстати, у себя гирман используем очень и очень много где и тоже подумываем переходить, привысоких нагрузках гирман начинает подтупливать, а именно выполняя одну очередь, забивает на другие полностью, и даже приоритеты задач не помогают.
Вода всегда кипяток, подошел и налил, никаких ожиданий пока вскипит и прочее, только воду доливай и все. Самое смешное, что стОит-то тех же денег, что и чайник нормальный. Советую!
А вот узнать про алгоритмы ценообразования и оптимизации стоимости было бы интересно!
Сам пытался выявить, не получилось, при чем до того не получилось, что пришлось поездом ехать, т.к. на нужный мне день цена взлетела в 3 раза, вместо того, чтобы упасть в полтора (на что я рассчитывал).
Просто после продолжительного времени работы БД под рельной большой нагрузкой мне сомнительно, что монго сама упала, хотя в Вашей формулировке это звучит именно так. Скорее я поверю, что вылетел сам сервер с битой памятью, развалившемся рейдом или оом-киллер убил монгу, потому что на сервере еще что-то располагалось кроме базы данных.
А вообще проблема, которую мы тут обсуждаем, — это издержки неправильной архитектуры (которая, к сожалению, в некоторых компаниях бывает из-за нежелания руководства выделять финансы на оверхед данных — репликацию).