Подписка на RSS

Как заниматься масштабированием, часть первая: не применяйте ничего лишнего

Верите вы или нет, но первая история произошла в середине 70-х.

Во время учебы в средней школе, мне повезло иметь доступ к миникомпьютеру Data General Nova. В отличие от других «космических» компьютеров, Новы были действительно очень крутыми. У них была возможность непрямой адресации, которая означала, что вы можете сделать любой адрес как непрямой, что заставит использовать этот адрес аппаратно как адрес адреса. Эта возможность делала вызовы и передачу параметров очень быстрой. Единственным недостатком была возможность зависания машины, если вы заставляли адрес ссылаться на самого себя).

Как бы то ни было, моей задачей было написать программу классификации. Эта программа должна была получать вход на оптических карточках (которые были как перфокарты, с тем отличием, что нужно было заполнять точечки карандашом, вместо того, чтобы пробивать отверстия), сравнивать ответы по ключу и выдавать всевозможные отчеты в качестве результата. Все просто, не так ли?

В те дни, операции ввода/вывода были очень медленными. По крайней мере, нам так рассказывали. Фактически, у нас не было никаких способов улучшить производительность, и я просто принял как данность, что ввод/вывод – очень медленный. Чтобы разобраться с этой проблемой, я решил использовать многозадачность. Я хотел использовать подзадачи, чтобы считывать карточки, в то время как основная задача выполняла классификацию. Крутая идея, да?

Итак, напомню вам:

  • Это была одна из первых программ, которых я писал в своей жизни.
  • Я решил использовать сложную, не до конца понятную технологию в проект, основываясь на интуиции. Большинство из нас не имело достаточного жизненного опыта в средней школе, чтобы правильно питаться, не говоря уж о интуитивных выборах технологий.
  • Все это программировалось на Фортране, который и сегодня не очень-то предназначен для многозадачности, а уж 40 лет назад…
  • В те дни не было Интернета. Онлайн вообще было мало что, особенно для уровня средней школы. Это означает, что единственным источником информации были бумажные руководства

.
Вы, наверное, не удивитесь, если я скажу, что результат был ужасный, и в конце концов ничего правильно не работало. Теперь я понимаю, что возможно оно бы все равно не работало, даже если бы я знал, что делаю.

Но главная моя ошибка была в том, что я использовал абсолютно ненужную вещь. Я поверил, что нашел МегаРешение (в моем случае – многозадачность).

Другие люди называют это «преждевременной оптимизацией», но я думаю, что здесь все глубже. Раз за разом я вижу, как люди используют технологию, или (еще хуже), пишут свою собственную, когда более простой подход сработал бы так же или даже лучше.

Другой пример возник спустя несколько лет в Macy’s. Мы были одними из первых установщиков электронных кассовых аппаратов IBM(да-да, IBM делали кассовые аппараты), что означало установку компьютера в каждый магазин и соединение его со всеми аппаратами в магазине. Верите или нет, но нужно было вручную настраивать софт для каждого магазина, настраивая каждый аппарат по отдельности. Будучи в самом низу иерархии (я ведь еще был подростком, помните?), я занимался именно этим.

Если бы я был умным подростком, я бы просто вбил всю эту конфигурацию и занимался своими делами. Всего было около 10 магазинов, и после первоначальной установки там что-то менялось бы раз в несколько месяцев. Но, так как я не был умным, я решил написать сложный макрос на ассемблере, который бы выполнял работу. Это примерно как писать программу для препроцессора C++ (#define, #ifdef, и т.д.), чтобы сгенерировать C-программу.

Это стоило мне недели бессонных ночей, когда я мог бы сконфигурировать каждый чертов магазин в округе, и, до кучи, все остальные супермаркеты за один день. Кроме того, я был единственным человеком, который понимал, как все это работает. Теперь я думаю, что мне очень повезло, что меня не уволили и не дали хорошую взбучку.

Не поймите меня неправильно. Я также провел тысячи полезных часов, разбираясь с новыми технологиями(фактически, я получил мою первую серьезную работу, потому что провел год в колледже занимаясь только МегаРешениями и ничем больше), для тренировки. Я только призываю не делать этого, когда вам платят за работу, или, еще хуже – вы делаете что-то, что придется сопровождать кому-то другому.

А теперь вернемся к сегодняшнему дню. Мы с другом думали о новом проекте, и наше внимание привлекла шумиха вокруг NoSQL (также посмотрите эту великолепную подборку NoSQL-решений). Мы оба используем базы данных практически с момента их создания (я обещаю замучить вас этим позже), и все плюсы и минусы реляционных баз данных нам хорошо известны.

Нашей первой реакцией было «Круто! Автоматическое маштабирование! Автоматическое шардирование! Автоматическое удаление SPOF!”

Наша вторая реакция: «Эээ, мм.. а как вы делаете отчеты? Каждое бизнес-решение требует новой программы?» (здесь прячется бизнес-идея для кого-то).

Ладно, я что-то отвлекся. Вопрос в другом – считать ли желание попробовать NoSQL-решения типа Cassandra погоней за очередным МегаРешением? Что ж, я думаю, и да, и нет, и у меня есть компромиссный вариант.

Да, потому что, мы ведь не работаем над Google, Digg, или eBay, и пока что тратить время и силы на попытки подогнать архитектуру под схему, совместимую с Cassandra – это не лучший способ использовать время.

Нет, это не потеря времени, потому что если у нас все получится, то нам не придется потом в панике что-то переделывать, когда мы вырастем, и мы сможем сосредоточиться на других вещах.

С другой стороны, если мы сейчас тратим время на работу с Cassandra, вместо того, что мы знаем (SQL), то это время потеряно для работы непосредственно над проектом.
Компромисс в том, чтобы инкапсулировать доступ к данным так, чтобы большая часть кода не зависела от того, используем мы MySQL, Oracle, Cassandra, или текстовые файлы. Имея опыт нескольких таких инкапсуляций, я могу сказать, что это не так трудно, если вы грамотно продумаете наперед все, что вы хотите сделать.

Итак, подведем итоги:

  • Остерегайтесь МегаРешений.
  • Занимайтесь МегаРешениями если ваше расписание, проект, работа и здравый смысл не противоречат этому.
  • Помните, что МегаРешения сложнее в использовании и отнимают больше времени чем скучные и банальные методы.
  • Используйте инкапсуляцию где это возможно, чтобы потом выбирать МегаРешениями, стандартными подходами, и чем-то совсем уж неизведанным
  • Не стесняйтесь заниматься МегаРешениями в качестве упражнения.

Спасибо за прочтение!

Автор статьи: Michael Wilson
Дата: 30 марта 2010
Оригинал статьи

Leave a Reply

Your email address will not be published. Required fields are marked *