Пол Букхейт: Секрет полегшення роботи: уникайте важких проблем

Це може зда­ти­ся оче­ви­дним, але, на мій досвід, біль­шість інже­не­рів вва­жа­ють за кра­ще зосе­ре­ди­ти­ся на важ­ких про­бле­мах. Робо­та над важ­ки­ми про­бле­ма­ми вра­жає інших інже­не­рів, але це не най­кра­щий спо­сіб ство­ре­н­ня успі­шних про­ду­ктів. Насправ­ді, це одна з кіль­кох при­чин, чому YouTube пере­міг Google Video: Google витра­тив бага­то часу на вирі­ше­н­ня техні­чно скла­дних про­блем, у той час як YouTube ство­рив про­дукт, яким люди дій­сно кори­сту­ва­ли­ся (вико­ри­сто­ву­ю­чи PHP та MySQL, що, я думаю, зов­сім не вра­жає технічно).

Для мене най­більш ефе­ктив­ним мето­дом швид­ко­го вирі­ше­н­ня зав­дань є обман (техні­чно), вико­ри­ста­н­ня без­лі­чі коро­тких шля­хів та пошук лег­шо­го спосо­бу обі­йти про­бле­му (і перш ніж хтось схо­пи­ться з комен­та­ря­ми про без­пе­ку чи бан­ків­ські опе­ра­ції, оче­ви­дно, є кіль­ка виня­тків). Вам потрі­бно лише дума­ти напе­ред, щоб не загна­ти себе в кут, або мати прав­до­по­ді­бний план вихо­ду з ньо­го. Зав­жди є лег­ший шлях — пра­цюй­те ліни­ві­ше, а не ста­ран­ні­ше. Звер­ніть ува­гу, що це не виклю­чає того, щоб роби­ти речі, які зда­ю­ться важ­ки­ми — лег­кі вирі­ше­н­ня важли­вих про­блем, які вигля­да­ють дій­сно важ­ки­ми, є найкращими.

Я зга­дав про це, від­по­від­а­ю­чи на комен­та­рі на news.yc у від­по­відь на мій пост про диски та бази даних. Щора­зу, коли хтось зга­дує про можли­вість не вико­ри­сто­ву­ва­ти зви­чай­ну базу даних, бага­то людей від­ра­зу ж від­по­від­а­ють, що бази даних вирі­шу­ють без­ліч дуже скла­дних про­блем, і що не вар­то докла­да­ти бага­то зусиль, щоб вина­хо­ди­ти коле­со. Ці люди, зви­чай­но, мають рацію.

Але річ у тому, що бага­то цих скла­дних про­блем неакту­аль­ні для 99% про­ду­ктів. Напри­клад, «справ­жні» бази даних можуть обро­бля­ти тран­за­кції, які над­то вели­кі, щоб помі­сти­ти­ся у пам’я­ті. Можли­во, 1980 року це було справ­ді важли­вою осо­бли­ві­стю. Сьо­го­дні ви може­те купи­ти ком­п’ю­тер із 32 ГБ пам’я­ті при­бли­зно за $5000. Як ви вва­жа­є­те, скіль­ки тран­за­кцій обся­гом у ГБ вико­нує Twitter? Моє при­пу­ще­н­ня – нуль. Я підо­зрюю, що сере­дній роз­мір тран­за­кції ближ­чий до 0,0000002 ГБ (пові­дом­ле­н­ня обме­же­но 140 символами).

Я хочу про­ясни­ти одну річ: я не раджу вам від­мо­ви­тись від бази даних! Якщо ваша база даних пра­цює досить швид­ко, то най­про­сті­ше, ймо­вір­но, «нічо­го не роби­ти», і саме це я раджу вам зро­би­ти. Однак, якщо ваша база даних пра­цює повіль­но або пере­ван­та­же­на, то вам потрі­бно зро­би­ти дві речі:

1. Зро­зу­мі­ти проблему
2. Усу­ну­ти проблему

Пра­виль­не вирі­ше­н­ня про­бле­ми зале­жа­ти­ме від вашої ситу­а­ції. Напри­клад, якщо у вас є деякі дані, які дуже важли­ві, але не змі­ню­ю­ться дуже часто (ім’я кори­сту­ва­ча та пароль), і деякі дані, які постій­но онов­лю­ю­ться, але не обо­в’яз­ко­во повин­ні бути пра­виль­ни­ми (остан­ній актив­ний час або лічиль­ни­ки пере­гля­дів), то про­стим ріше­н­ням буде зали­ши­ти важли­ві дані у вашій базі даних і пере­мі­сти­ти менш важли­ві дані у щось дій­сно про­сте, але менш надійне.

Хоче­те при­клад «‎про­сто­го, але менш надій­но­го»? Ось один з них (в один або два про­стих кроки):

1. Всі онов­ле­н­ня над­хо­дять до Memcached, але не до бази даних.
2. (опціо­наль­но) Фоно­вий про­цес пері­о­ди­чно копі­ює запи­си з memcached до бази даних. Без цьо­го зна­че­н­ня будуть пов­ні­стю втра­че­ні при пере­за­пу­ску Memcached.