Ну, про разработчиков-то понятно, я за трекером на Ланчпаде слежу более-менее сам.
Хотелось-то отзыва от человека, который сам по себе бету завёл и попользовался.
По ощущениям после года использования — нет, это не Гном Шелл.
Пантеон — самый шустрый и непадучий из мышечных ДЕ, с которыми мне приходилось работать.
Ну, по общей логике — смотреть на положительный опыт Фейсбука мне имеет смысл когда у нас задачи сопоставимые (по нагрузке, по объёмам).
Это не так приблизительно для 100% участвующих в подобных дебатах в интернете.
Ну и да, между строк Вы подразумеваете, что NoSQL у Фейсбука не от хорошей жизни, а просто потому что данных слишком много и обычный SQL перестал справляться, а так бы он и был.
Собственно да, так оно и есть.
А что не так с git-completion в баше в стандартной поставке Убунты?
Сам пользуюсь фишем, где всё вообще волшебно, но только что проверил — в баше тоже в команде git pull origin bug-647 автодополнились все 4 слова, к месту и разумным образом.
Может есть какие-то вообще магические вещи, а я и не в курсе?
Я правильно понимаю, что вы все вместе работаете в одной ветке?
Потому что я бывал в подобной ситуации на поза-поза прошлом проекте. Как только всем было выдано в мозг и предписание выучить и использовать git flow (парадигму, а не тулзу; хотя тулза зачётная), проблемы исчезли.
Ну, я бы эти данные истолковал не как «есть вероятность в полтора процента, что у пользователя закешировалась нужная вам версия jQuery», а как «у пользователей уже есть дохренища версий jQuery в кеше, выбирай любую».
Шардинг из коробки, гибкое управление фактором репликации, устойчивость к потере узлов, автобалансировка записи без единой точки отказа, линейное масштабирование (по объёму хранилища и скорости записи) при добавлении новых узлов, возможность добавлять новые узлы «на лету» (с оговорками, правда).
master dataset — это место, куда валится всё-всё что на входе, до разбора и преобразований. (Уточню на всякий случай: мы обсуждаем систему, которая более-менее в реалтайме выдаёт аналитику для десятков тысяч событий в секунду. Логи там, отчёты всякие.)
Использовать под мастер датасет РСУБД безумие. Потому что транзакционная природа тут ни к чему, ибо данные не мутабельны. Одна строка — одно событие, бывают только insert или select. За транзакции для этого мы заплатим скоростью вставки и большей централизацией (хотя бы для координации блокировок), что сделает всю систему хрупче.
У нас на уровне этого самом мастер датасета ровно одна задача — проглотить и надёжно сохранить все входящие. Много входящих.
Потом уже эти данные пересчитываются пачками (при помощи канонического Map/Reduce) и, в качестве бонус-трека, потоково (при помощи стрим процессора какого-нибудь, типа Storm).
Производные данные как раз-таки хорошо хранятся в РСУБД. Это именно они читаются с клиентов, и именно тут транзакционность может быть критичной. Потому что производные данные — это суть свёртки, и для них на сцену выходят апдейты имеющихся рядов.
И там Кассандра занимает место [2] (master dataset), которое Вы отводите файлам (у которых с ссылочной целостностью тоже не очень, насколько я понимаю).
Сваливание в файлы невозможно ускорить по записи втрое, подключив ещё несколько узлов. И репликация (replication_factor у Кассандры) на несколько узлов с автошардингом — нетривиальная для файлового хранилища задача, на самом деле.
Автомобилизация, увы, кроме благосостояния нации вообще ничего не показыаает.
Попробуйте повторить свой аргумент, воспользовавшись сравнением по параметру «автомобилепользование».
Скорее многие стартапы от старта отделяет дефицит кадров на рынке США. (И как следствие — высокие зарплаты. И как следствие — необходимость бóльших денег для старта. Предложение на рынке выростет, цена просядет, больше чуваков стартуют за меньшие бюджеты.)
Хотелось-то отзыва от человека, который сам по себе бету завёл и попользовался.
С Лýны уже можно переходить без вреда рабочему процессу?
Пантеон — самый шустрый и непадучий из мышечных ДЕ, с которыми мне приходилось работать.
Гроб-гроб-кладбище.
Серъёзно.
Думайте про ЕС-овский Blue Card или Канаду/Австралию.
Это не так приблизительно для 100% участвующих в подобных дебатах в интернете.
Ну и да, между строк Вы подразумеваете, что NoSQL у Фейсбука не от хорошей жизни, а просто потому что данных слишком много и обычный SQL перестал справляться, а так бы он и был.
Собственно да, так оно и есть.
Сам пользуюсь фишем, где всё вообще волшебно, но только что проверил — в баше тоже в команде
git pull origin bug-647автодополнились все 4 слова, к месту и разумным образом.Может есть какие-то вообще магические вещи, а я и не в курсе?
Потому что я бывал в подобной ситуации на поза-поза прошлом проекте. Как только всем было выдано в мозг и предписание выучить и использовать git flow (парадигму, а не тулзу; хотя тулза зачётная), проблемы исчезли.
А так да, осталось ещё один малюсенький шажок сделать, и мы изобретем ActiveRecord Migrations и seed.rb пророк его.
Шардинг из коробки, гибкое управление фактором репликации, устойчивость к потере узлов, автобалансировка записи без единой точки отказа, линейное масштабирование (по объёму хранилища и скорости записи) при добавлении новых узлов, возможность добавлять новые узлы «на лету» (с оговорками, правда).
(Уточню на всякий случай: мы обсуждаем систему, которая более-менее в реалтайме выдаёт аналитику для десятков тысяч событий в секунду. Логи там, отчёты всякие.)
Использовать под мастер датасет РСУБД безумие. Потому что транзакционная природа тут ни к чему, ибо данные не мутабельны. Одна строка — одно событие, бывают только insert или select. За транзакции для этого мы заплатим скоростью вставки и большей централизацией (хотя бы для координации блокировок), что сделает всю систему хрупче.
У нас на уровне этого самом мастер датасета ровно одна задача — проглотить и надёжно сохранить все входящие. Много входящих.
Потом уже эти данные пересчитываются пачками (при помощи канонического Map/Reduce) и, в качестве бонус-трека, потоково (при помощи стрим процессора какого-нибудь, типа Storm).
Производные данные как раз-таки хорошо хранятся в РСУБД. Это именно они читаются с клиентов, и именно тут транзакционность может быть критичной. Потому что производные данные — это суть свёртки, и для них на сцену выходят апдейты имеющихся рядов.
И там Кассандра занимает место [2] (master dataset), которое Вы отводите файлам (у которых с ссылочной целостностью тоже не очень, насколько я понимаю).
Сваливание в файлы невозможно ускорить по записи втрое, подключив ещё несколько узлов. И репликация (replication_factor у Кассандры) на несколько узлов с автошардингом — нетривиальная для файлового хранилища задача, на самом деле.
По состоянию на 2.4 встроенный джаваскриптовый M/R был чудовищно медленным и не параллелился.
Всё продумано, всё разумно, даже стандарт Cripple AMD поддерживается.
Попробуйте повторить свой аргумент, воспользовавшись сравнением по параметру «автомобилепользование».