All streams
Search
Write a publication
Pull to refresh
-13
0
Павел Сутырин @spacediver

User

Send message
Что-то я не видел оборотов и контрагентов в выписках из ЕГРЮЛ ;)

Насчет кучи фирм — более чем согласен. Спросил однажды опытнейшего российского предпринимателя: типа, ну а как отожмут бизнес, siloviki, мафия? Он ответил так: «если в бизнесе придраться не к чему, то и пытаться не будут».
омг, а когда это она была открыта?
Пару месяцев назад ODesk присылал мне русско-английский договор по запросу в хелпдеск. Собственно, могу выслать файлик в личку. Но лучше у них уточнить :)
DSL же. Rake, Chef как минимум.
хм, а как они с лицензией решат?
в ядре хоста или гостя? наверное, гостя :)
А что про IPv6?.. Их-то можно будет не экономить?
Н-да, по-моему, вы имели в виду «не заглядывая под череп». :) Sorry for inconvenience.
Коллега высказался на тему: «виртуальные диски имеют непостоянный latency, поэтому ставить на них продукционную СУБД, от отклика которой напрямую зависит latency всего приложения — не вариант».

Оставаясь иррациональным приверженцем облачного хостинга, размышляю — либо нужно искать варианты гарантировать latency виртуальных дисков, либо думать в сторону такой архитектуры приложений, которая бы меньше страдала от кратковременных залипаний СУБД (СХД). В частности, стремиться хранить все в RAM и очень редко и бережно (читай — пакетно) работать с дисками.

Алсо, опять же на уровне прикладной архитектуры, можно подключить к виртуальной машине несколько виртуальных дисков, попросив хостера «распределить» их по СХД, чтобы вероятность «залипания» всех сразу была сильно меньше. На основе этого набора дисков сконструировать что-то вроде программного RAID с требуемыми свойствами (параллельная обработка запросов и преимущественно быстрый ответ хотя бы от одной реплики + eventual consistency), на котором и держать дисковые страницы СУБД. Основной concern, видимо здесь — запросы на запись.

Либо же сделать это же, но на уровне хостов — кластерная СУБД. Тогда уже она будет следить, чтобы SQL-запрос коммитнулся хотя бы на одну из реплик (угу, это сразу не master-slave).

А вообще это все начинает попахивать NoSQL :))

Вобщем, я знаю, что как минимум Heroku и Dropbox работают 100% (или чуть менее) на облачном хостинге, и ведь как-то они это делают!
Я слабо понимаю в СХД — а у них есть внутренний мониторинг на эту тему? Если хотя бы по виртуальным дискам статистика запросов разбивается, то уже можно говорить о конкретной де-факто статистике для определенной машины.

И еще вопрос по поводу конкретно вашей СХД. Положим, я выкачиваю с Хранилища файло 2-3 Гб на максимальной скорости (из Питера в Питер выходит даже до 25-40 Мбайт/сек) — что при этом происходит с производительностью для других клиентов?.. Ибо иной раз я по несколько минут наблюдаю скорость не выше 1 Мбайт/сек. Подозреваю тут балансировку нагрузки — буду признателен, если напишете о ней подробнее.
Да, примерно такой SLA я и имел в виду.
куда более ценная нажива

Интеллектуальная собственность, поди?
Плюсанул, даже под кат не заглядывая. Редкий случай.
Или, положим, резервировать приоритетное обслуживание запросов (очередь с приоритетами), чтобы гарантировать себе предсказуемый latency.
Я вот думаю, а как можно помочь хостеру лучше предоставлять нам виртуальные диски?.. Положим, предложить резервировать полосу до дисков, или что-нибудь в этом роде. Или же пока тупо архитектурно выносить disk-intensive MySQL на выделенный железный сервер?
Подождите, это как — сам заливает???

Заходишь на сайт, нажимаешь «Upload», потом получаешь ссылку на файл… разве нет???
Да, очень странно сгруппированы карты, по 3-4 колоды в стопке. Как я понял, он отбирает колоду из стопки до определенной карты.
я писал системы управления, вполне сравнимые по сложности

с самообучением?
… смотрит на Бакстера с неодобрением.

Information

Rating
6,312-th
Location
Россия
Registered
Activity