Извините, а в чем преимущества Visual Studio Express (мы же об обучении говорим?) перед QtCreator?
P.S. Насколько у меня сохранились воспоминания несколько-летней давности (2010 студия, вроде, была тогда) это был жуткий тормоз, который почти никак не умел парсить и автокомплитить C++, но это могло и поменяться.
а как быть в случае, когда нужно хранить много файлов с одинаковыми именами?
Для этого можно хранить их в разных namespace'ах, тогда немного по другому будет считаться hash-сумма и у них в итоге будут разные идентификаторы.
Второй вопрос, вот существует приложение которое работает с Elliptics, оно обращается к кластеру по какому-то ip-адресу, который принадлежит какой-либо ноде (предполагаю), и тут нода падает и ip-адрес становится недоступным. Соответственно приложение теряет кластер из виду. Как устраняется такая ситуация? Разъясните этот момент (хотя предполагаю что запущено несоклько прокси и у «приложения» есть список адресов кластера).
Как правило у нас запущено какое-то количество proxy-серверов, над которым стоит некоторое количество балансировщиков. В итоге приложения идут по dns-имени балансировщиков, а они уже, в свою очередь, раскидывают запросы по проксям.
В них есть веская причина использовать эти суррогатные пары.
Насколько мне известно, то этой причиной является потребление памяти. Если использование utf-16 еще осмысленно (т.к. большинство языков в utf-8 не помещается в 1 байт), то utf-32 уже является перебором. Мало кто захочет платить в 2 раза больше за тоже самое.
Нет, wchar_t — legacy, которое часто путают с юникодом.
Но при этом на современных системах — это, как правило, 2 или 4 байта. Для гарантии можно, конечно же, использовать char16_t или char32_t, которые гарантированно представляют из себя utf-16 и utf-32 соответственно.
Это — два совершенно разных языка. С на порядки проще.
Так никто и не заставляет окунаться во все дебри C++, вначале — Си, потом классы, потом уже шаблоны и т.д. В физике же тоже начинают не сразу с квантовой механики, но при этом курс все равно называется «физика».
Ну да, шаблоны в начале обучения программированию — прекрасная идея.
Использование функционального подхода в начале программирования — в принципе плохая идея. Его стоит давать только после обучения лямбда-исчислению.
В плюсах появилось функциональное программирование?
Метапрограммирование на шаблонах — чистой воды функциональщина.
Char — не символ (потому, что юникод).
На этот случай есть wchar_t, который вполне себе юникод.
Указатель на первый из них — не строка.
Имеется std::string, std::wstring, по мне, так они вполне себе строки.
Смысл начинать с него?
Я начинал с C/C++, и мне кажется, что это наиболее правильный путь к обучению. Во время обучения программированию должно быть по минимуму черных ящиков, чтобы ученик/студент понимал принцип работы, почему и зачем все происходит.
Разумеется не нужно вываливать на обучающихся все сразу, но если давать это правильными порциями, то будет конфетка.
Потому что разработчики ceph хотели предоставить возможность пользователям самим решать что для них лучше, если им не нравятся настройки по умолчанию.
Мы тоже не решаем за пользователей — все настройки, которые имеют смысл, выносятся в конфигурационный файл. Если вам известны опции, которые хотелось бы настраивать — дайте знать, а лучше — присылайте pull request :)
без сишного api замечательно жить в яндексе. А на остальных вам положить.
Опять же, если найдутся люди, которым будет нужен сишный API, то можно говорить, пока что мне о них не известно.
А у меня меньше. И я не хочу держать к elliptics ещё и индекс где-то.
В таком случае вам наверняка подойдут вторичные индексы, которые уже есть в Elliptics!
тут проблема в понимании сути стабильной версии: обычно в стабильную версию портируются исправления ошибок из текущей версии.
Как тогда вы объясните, что новая LTS версия со старой будет пересекаться по времени жизни в полгода? В течение этого времени будут backport'ироваться все исправления ошибок, а так же фичи, которые не ломают API и ABI.
Мы держим по копии в каждой группе, суммарно 3 копии…
Даже если третий сервер вернет «no such file», то копии есть еще в 2 группах, куда клиент и сходит, чтобы достать нужный файл, при этом запустится процедура автоматического восстановления и файл зальется на сервер, где он по каким-то причинам потерялся. После этого файл будет снова в трех копиях.
Как правило при передачи больших файлов упираемся не в диск, а в сеть. Вот смотрим: один диск в состоянии читать данные со скоростью, допустим, 100 мегабайт в секунду, сеть, как правило, стоит гигабитная, то есть почти такая же.
Более того, на каждой машине стоит полка из нескольких десятков дисков, что уже многократно перекрывает возможности даже десятигигабитной сети.
Как бы мы не разносили файл на разные машины — мы все равно не сможем его отдать быстрее.
Так же стоит отметить, что на наших задачах файлов, как правило, очень много, поэтому поэтому к машинам обращаются более-менее равномерно.
Мы достаточно эффективно храним файлы размером от единиц килобайт до нескольких гигабайт. На диске данные хранятся в блобах, как правило, по несколько миллионов ключей в файле.
С данными большего объема теоретически могут возникнуть проблемы, но тестирований еще не проводили, да и нужды не было.
Мы считаем sha512 от имени файла, получаем соответствующий записи ключ
У нас всегда есть свежая таблица маршрутизации для всех групп, в ней мы храним только начала секторов, принадлежащих машине, поэтому она имеет небольшой размер и спокойно помещается в памяти
По таблице маршрутизации за O(1) всегда можно узнать для каждой из групп где должен лежать файл
Поэтому ответ на этот вопрос всегда можно дать за O(1) из любого места Elliptics Network.
Ок, а как у вас обстоят дела с решением конфликтов после split brain?
Есть несколько подходов:
Просто часы, это подходит в большинстве случаев
Можно построить свои векторные часы на основе примитивов Elliptics, например, с помощью Lookup и атомарного Compare&Swap (в таком случае главную роль играет sha512 чексумма данных)
А можно отдавать только те данные, которые ближе :) Это корректно, когда мы точно знаем, что данные не переписываются, а отдавать их нужно как можно быстрее
Очевидно, что эти системы имеют много общего, так как обе были написаны под воздействием драфта Amazon Dynamo, опубликованного в далеком 2006 году.
А теперь по пунктам:
У Riak более-менее нормальная кросс-датацентровая репликация данных есть только в платной версии
Насколько мне известно, в Riak странно устроена репликация данных. Все машины там пронумерованы, причем каждая, например, двойка подряд идущих машин хранит свою часть кольца. Поэтому если добавить машину «как-то не так», то произойдет почти полная перекачка всех данных внутри дата-центра. Так же это накладывает ограничение на количество добавляемых машин, их количество должно быть кратным количеству копий
Backend Riak'а потребляет гораздо больше памяти, чем наш eblob
Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)
Это то, насколько мне известно, что у Riak плохо. Но для проведения более детального сравнения нужен кто-нибудь, кто очень хорошо разбирается в Riak, тогда мы готовы побеседовать :) Так же мы готовы пострелять и сравнить обе системы в плане производительности
Нужно очень много читать книги/смотреть фильмы на английском, тогда от пути образ->русский->английский мозг перейдет на образ->английский, без ручного перевода предложений.
Я сам нифига не способен к изучению других языков, никогда не получалось специально выучить никакие правила/слова, но от постоянного использования языка такая схема образоваться смогла.
Это риторический вопрос? Наверное они разумно решили, что переписывать тонны софта с уже работающих решений на их собственные изобретения никто не будет.
Ну и плюсом, сделать свой storage-балалайку просто офигенно не тривиально, а они портом то занимались порядка двух лет.
P.S. Насколько у меня сохранились воспоминания несколько-летней давности (2010 студия, вроде, была тогда) это был жуткий тормоз, который почти никак не умел парсить и автокомплитить C++, но это могло и поменяться.
Для этого можно хранить их в разных namespace'ах, тогда немного по другому будет считаться hash-сумма и у них в итоге будут разные идентификаторы.
Как правило у нас запущено какое-то количество proxy-серверов, над которым стоит некоторое количество балансировщиков. В итоге приложения идут по dns-имени балансировщиков, а они уже, в свою очередь, раскидывают запросы по проксям.
Но я бы не сказал, что это «наше счастье» — выбор на printf/puts пал вполне осознанно в виду его возвращаемого значения.
Насколько мне известно, то этой причиной является потребление памяти. Если использование utf-16 еще осмысленно (т.к. большинство языков в utf-8 не помещается в 1 байт), то utf-32 уже является перебором. Мало кто захочет платить в 2 раза больше за тоже самое.
Но при этом на современных системах — это, как правило, 2 или 4 байта. Для гарантии можно, конечно же, использовать char16_t или char32_t, которые гарантированно представляют из себя utf-16 и utf-32 соответственно.
Так никто и не заставляет окунаться во все дебри C++, вначале — Си, потом классы, потом уже шаблоны и т.д. В физике же тоже начинают не сразу с квантовой механики, но при этом курс все равно называется «физика».
Использование функционального подхода в начале программирования — в принципе плохая идея. Его стоит давать только после обучения лямбда-исчислению.
Метапрограммирование на шаблонах — чистой воды функциональщина.
На этот случай есть wchar_t, который вполне себе юникод.
Имеется std::string, std::wstring, по мне, так они вполне себе строки.
Я начинал с C/C++, и мне кажется, что это наиболее правильный путь к обучению. Во время обучения программированию должно быть по минимуму черных ящиков, чтобы ученик/студент понимал принцип работы, почему и зачем все происходит.
Разумеется не нужно вываливать на обучающихся все сразу, но если давать это правильными порциями, то будет конфетка.
Не понимаю, что здесь сложного или непонятного. А потом уже можно ввести понятия типов данных, инклудов и т.д.
Мы тоже не решаем за пользователей — все настройки, которые имеют смысл, выносятся в конфигурационный файл. Если вам известны опции, которые хотелось бы настраивать — дайте знать, а лучше — присылайте pull request :)
Опять же, если найдутся люди, которым будет нужен сишный API, то можно говорить, пока что мне о них не известно.
В таком случае вам наверняка подойдут вторичные индексы, которые уже есть в Elliptics!
Как тогда вы объясните, что новая LTS версия со старой будет пересекаться по времени жизни в полгода? В течение этого времени будут backport'ироваться все исправления ошибок, а так же фичи, которые не ломают API и ABI.
Давайте поговорим об этом в публичной рассылке?
Даже если третий сервер вернет «no such file», то копии есть еще в 2 группах, куда клиент и сходит, чтобы достать нужный файл, при этом запустится процедура автоматического восстановления и файл зальется на сервер, где он по каким-то причинам потерялся. После этого файл будет снова в трех копиях.
Более того, на каждой машине стоит полка из нескольких десятков дисков, что уже многократно перекрывает возможности даже десятигигабитной сети.
Как бы мы не разносили файл на разные машины — мы все равно не сможем его отдать быстрее.
Так же стоит отметить, что на наших задачах файлов, как правило, очень много, поэтому поэтому к машинам обращаются более-менее равномерно.
С данными большего объема теоретически могут возникнуть проблемы, но тестирований еще не проводили, да и нужды не было.
Поэтому ответ на этот вопрос всегда можно дать за O(1) из любого места Elliptics Network.
Хотя, может, я и некорректно понял ваш вопрос, не могли бы вы его пояснить?
Есть несколько подходов:
А теперь по пунктам:
Это то, насколько мне известно, что у Riak плохо. Но для проведения более детального сравнения нужен кто-нибудь, кто очень хорошо разбирается в Riak, тогда мы готовы побеседовать :) Так же мы готовы пострелять и сравнить обе системы в плане производительности
Я сам нифига не способен к изучению других языков, никогда не получалось специально выучить никакие правила/слова, но от постоянного использования языка такая схема образоваться смогла.
Ну и плюсом, сделать свой storage-балалайку просто офигенно не тривиально, а они портом то занимались порядка двух лет.