Аверин Сергей, BadooРаспространенные ошибкиприменения баз данных
• Социальная сеть для знакомств с новыми людьми• В Top-200 Alexa c 2007 года• 180+ миллионов зарегистрированных пользовате...
7 советов стартапам
1. Масштабирование
Масштабирование• Стартап тратит кучу сил и времени на «готовность» к highload,большому масштабированию• Тратим большие рес...
Масштабирование• Стартап тратит кучу сил и времени на «готовность» к highload,большому масштабированию• Тратим большие рес...
МасштабированиеЧто имеем
МасштабированиеЧто рассчитываем получить
МасштабированиеСпособ масштабирования
Масштабирование• «Серебряной пули» масштабирования нет• Проблемы будут уникальными для вашего проекта• Понадобится творчес...
Масштабирование• Для стартапа главными ценностями являются быстрый старт идешевизна изменений• Начните с простых, быстрых ...
2. Отказоустойчивость
Отказоустойчивость• При проектировании архитектуры проблемы нижних уровней вовнимание не принимаются• Железо, человеческий...
ОтказоустойчивостьКак это сделано в Баду, на примере пользовательских данных:Выделенные БД-серверы• проверенного вендора• ...
ОтказоустойчивостьКак это сделано в Баду, на примере пользовательских данных:Софт• фаервол• Percona Server• разные права д...
ОтказоустойчивостьКак это сделано в Баду, на примере пользовательских данных:Архитектура• запись в транзакции, на один сер...
3. БД c запасом на вырост
БД c запасом на вырост• Выбирается БД без большого запаса фич, которые могутпонадобиться в будущем• Ни один стартап не ста...
4. БД — хранилище событий
БД — хранилище событийИспользование БД как хранилища событий чаще всегооправдано только леньюРаспространенные use case’ы:•...
БД — хранилище событийCпециализированный движок — RabbitMQ, Kestrel, Scribe, и дажеRedis:• скорость• простота• фичи• масшт...
БД — хранилище событийВ Баду для некоторых задач используем Scribe:• своя обертка с агрегацией данных, вставкой в БД• мень...
Старые песни о главном
5. Поиск
Поиск• Либо быстро, просто, плохо• Либо используем бесплатный движок —Sphinx, Solr, Lucene/ElasticSearch
Поиск99% случаев — быстро, просто, плохо:SELECT `id`, `body` FROM `entries` WHERE `body` LIKE %one%
Поиск99% случаев — быстро, просто, плохо:SELECT `id`, `body` FROM `entries` WHERE `body` LIKE %one%SELECT `id`, `body` FRO...
Поиск99% случаев — быстро, просто, плохо:Some people, when confronted with a problem, think“I know, I’ll use regular expre...
Поиск99% случаев — быстро, просто, плохо:• потом используем MySQL FULLTEXT Index• для простых решений прекрасно работает о...
Поиск99% случаев — быстро, просто, плохо:• а для каких-то задач просто неприменимоТест Percona: индекс по всем статьям Вик...
ПоискИспользуйте специализированный софт:• проще в разработке• быстрее• больше возможностей• масштабируется• а главное, лу...
6. Сильная consistency
Сильная consistency• Не всегда нужна в вебе• Часто сложно достигаема• Особенно, когда данные в один сервер не помещаются и...
Сильная consistency• Eventual consistency рулит• Можно писать в базу выборочно или писать агрегированныеданные, не нагружа...
Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses ...
Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация
Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш
Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш+ добавляем еще slave’ов — репликация реп...
Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш+ добавляем еще slave’ов — репликация реп...
Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш+ добавляем еще slave’ов — репликация реп...
Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses ...
Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses ...
Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses ...
7. Используйте хорошоизученные инструменты
Используйте хорошоизученные инструменты• Неизвестность → опасность• Выше скорость разработки• Не поддавайтесь просто так н...
Используйте хорошоизученные инструменты“Психологическая” популярность NoSQL:• marketing hype• мало знаний в области SQL: A...
Используйте хорошоизученные инструменты“Психологическая” популярность NoSQL:Идеальная БД для программиста• хранит объекты ...
Используйте хорошоизученные инструменты“Психологическая” популярность NoSQL:Выбор БД• техн. менеджмент спускает вопрос на ...
Используйте хорошоизученные инструментыNoSQL:− запись в один поток− memory-mapped files, IO scheduling не для БД− один инд...
Используйте хорошоизученные инструментыNoSQL:− зачастую приходится писать кучу довольно скучного кода науровне приложения+...
Используйте хорошоизученные инструментыSQL:− медленнее− сложнее(−) много каверзных настроек− в редких случаях непредсказуе...
Используйте хорошоизученные инструментыSQL:+ более популярно, язык у всех на 80% совпадает+ хорошо изучено, стабильно+ опт...
Используйте хорошоизученные инструментыSQL:(+) Joinы, которые зло, но иногда выручают+ очень навороченный оптимизатор запр...
EVERYBODY LIESВыводов нет, думайте своей головой!
Вопросы?Аверин Сергейtwitter.com/ryba_xeks@averin.ruaverin.ru/slides/We’re hiring!
Upcoming SlideShare
Loading in...5
×

Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения баз данных".

838
-1

Published on

Доклад не про БД в чистом виде а про архитектуру веб-приложений, использующих БД.
Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.
Подробно:
• Зачастую в стартапе изначально проектируется архитектура вокруг БД, рассчитанная на огромные нагрузки, на большое масштабирование, которые потом в реальной жизни никогда не понадобятся.
• Или проектируется архитектура, которая якобы дает отказоустойчивость, но при этом проблемы нижних уровней абстракции во внимание не принимаются.
• При выборе основной БД для проекта выбирается БД, которая не дает большого запаса фич в будущем, появляется дороговизна и сложность изменения.
• Используйте инструменты, которые вы хорошо изучили. «Психологическая» популярность NoSQL. Достоинства и недостатки SQL и NoSQL БД.
• Проблемы использования БД как хранилища/движка обработки событий зачастую не оправдано. Альтернативы.
• Использование БД для поиска, плюсы и минусы.
• Eventual consistency рулит, и как из этого можно извлечь пользу.
Целевая аудитория:
Доклад будет интересен веб-разработчикам, особенно из стартапов и небольших команд, техническим руководителям.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
838
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
15
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Доклад Сергея Аверина на DevConf 2013. "Распространенные ошибки применения баз данных".

  1. 1. Аверин Сергей, BadooРаспространенные ошибкиприменения баз данных
  2. 2. • Социальная сеть для знакомств с новыми людьми• В Top-200 Alexa c 2007 года• 180+ миллионов зарегистрированных пользователей• 150+ тысяч новых пользователей в день• 3+ миллиона фотографий загружаются ежедневно• 2+ тысячи серверов• 30+ тысяч запросов в секунду к бекендам• MySQL, PHP, C(++), Linux, nginx, PHP-fpm, memcache— это:
  3. 3. 7 советов стартапам
  4. 4. 1. Масштабирование
  5. 5. Масштабирование• Стартап тратит кучу сил и времени на «готовность» к highload,большому масштабированию• Тратим большие ресурсы без быстрой отдачи• Сложные вопросы не рассматриваются по причине того, чтомало опыта или проблемы еще не понятны
  6. 6. Масштабирование• Стартап тратит кучу сил и времени на «готовность» к highload,большому масштабированию• Тратим большие ресурсы без быстрой отдачи• Сложные вопросы не рассматриваются по причине того, чтомало опыта или проблемы еще не понятныНа самом деле, это предполагет, что ваши бизнес-метрикитоже вырастут в десятки и сотни раз, а архитектурасохранится
  7. 7. МасштабированиеЧто имеем
  8. 8. МасштабированиеЧто рассчитываем получить
  9. 9. МасштабированиеСпособ масштабирования
  10. 10. Масштабирование• «Серебряной пули» масштабирования нет• Проблемы будут уникальными для вашего проекта• Понадобится творческое решение• И многое придется переделывать
  11. 11. Масштабирование• Для стартапа главными ценностями являются быстрый старт идешевизна изменений• Начните с простых, быстрых и несложных решений «порецепту»• Клиенты → опыт → понимание, какая архитектура нужнаК. О. предупреждает: истиной для 100%случаев не является
  12. 12. 2. Отказоустойчивость
  13. 13. Отказоустойчивость• При проектировании архитектуры проблемы нижних уровней вовнимание не принимаются• Железо, человеческий фактор, внешние риски и т. д.• Взаимосвязанность сбоев• В рамках одного сервера на практике не бывает
  14. 14. ОтказоустойчивостьКак это сделано в Баду, на примере пользовательских данных:Выделенные БД-серверы• проверенного вендора• резервирование по питанию• RAID 1+0
  15. 15. ОтказоустойчивостьКак это сделано в Баду, на примере пользовательских данных:Софт• фаервол• Percona Server• разные права доступа• chroot-окружение
  16. 16. ОтказоустойчивостьКак это сделано в Баду, на примере пользовательских данных:Архитектура• запись в транзакции, на один сервер• синхронизация с другим ДЦ через общую очередь
  17. 17. 3. БД c запасом на вырост
  18. 18. БД c запасом на вырост• Выбирается БД без большого запаса фич, которые могутпонадобиться в будущем• Ни один стартап не становился огромным в один день• Узкоспециализированные БД → теряется гибкость• NoSQL → нет возможности делать сложные вещи худо-бедно,но ценой малых затрат на кодирование
  19. 19. 4. БД — хранилище событий
  20. 20. БД — хранилище событийИспользование БД как хранилища событий чаще всегооправдано только леньюРаспространенные use case’ы:• события, порожденные транзакциями• события, которые должны надежно доставляться• события, которые можно потерять
  21. 21. БД — хранилище событийCпециализированный движок — RabbitMQ, Kestrel, Scribe, и дажеRedis:• скорость• простота• фичи• масштабируемость
  22. 22. БД — хранилище событийВ Баду для некоторых задач используем Scribe:• своя обертка с агрегацией данных, вставкой в БД• меньше сетевых соединений• передаем данные между ДЦ• гибкие настройки• при сбоях сохраняет данные локально• очень быстрый
  23. 23. Старые песни о главном
  24. 24. 5. Поиск
  25. 25. Поиск• Либо быстро, просто, плохо• Либо используем бесплатный движок —Sphinx, Solr, Lucene/ElasticSearch
  26. 26. Поиск99% случаев — быстро, просто, плохо:SELECT `id`, `body` FROM `entries` WHERE `body` LIKE %one%
  27. 27. Поиск99% случаев — быстро, просто, плохо:SELECT `id`, `body` FROM `entries` WHERE `body` LIKE %one%SELECT `id`, `body` FROM `entries` WHERE `body` RLIKE[[:<:]]one[[:>:]]http://www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql
  28. 28. Поиск99% случаев — быстро, просто, плохо:Some people, when confronted with a problem, think“I know, I’ll use regular expressions.”Now they have two problems.— Jamie Zawinsky
  29. 29. Поиск99% случаев — быстро, просто, плохо:• потом используем MySQL FULLTEXT Index• для простых решений прекрасно работает обратный индекс• Но с полноценным поиском по тексту проблема в том, чтопросто плохо ищет =)• а также: мало фич, медленно, хуже масштабируется
  30. 30. Поиск99% случаев — быстро, просто, плохо:• а для каких-то задач просто неприменимоТест Percona: индекс по всем статьям Википедии.2,5 млн записей, 15 Гб текста на одном сервере• Sphinx: 20 минут• MySQL: админ уснул через 6 часов, так и не дождавшисьhttp://www.percona.com/files//presentations/opensql2008_sphinx.pdf
  31. 31. ПоискИспользуйте специализированный софт:• проще в разработке• быстрее• больше возможностей• масштабируется• а главное, лучше ищет
  32. 32. 6. Сильная consistency
  33. 33. Сильная consistency• Не всегда нужна в вебе• Часто сложно достигаема• Особенно, когда данные в один сервер не помещаются и надочто-то придумывать
  34. 34. Сильная consistency• Eventual consistency рулит• Можно писать в базу выборочно или писать агрегированныеданные, не нагружая БД• Денормализация может дать большой приростпроизводительности• Важно знать меру, и что мы теряем, а что получаем
  35. 35. Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses relational algebra to access normalized tables.’
  36. 36. Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация
  37. 37. Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш
  38. 38. Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш+ добавляем еще slave’ов — репликация репликации
  39. 39. Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш+ добавляем еще slave’ов — репликация репликации+ шардинг
  40. 40. Сильная consistencyЧтобы не получилось так:+ добавляем slave — репликация+ мемкеш+ добавляем еще slave’ов — репликация репликации+ шардинг+ один столбец на таблицу, храним в нем сериализованныйобъект
  41. 41. Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses relational algebra to access normalized tables.’
  42. 42. Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses relational algebra to access normalized tables.’Много данных кривые руки
  43. 43. Сильная consistencyЧтобы не получилось так:SQL DB = ‘A consistent transactional datastore with schema guaranteesthat uses relational algebra to access normalized tables.’‘A consistent transactional datastore with schema guarantees that usesrelational algebra to access normalized tables.’= datastore with access to data, лучше и не скажешьhttp://www.youtube.com/watch?v=zAbFRiyT3LUМного данных кривые руки
  44. 44. 7. Используйте хорошоизученные инструменты
  45. 45. Используйте хорошоизученные инструменты• Неизвестность → опасность• Выше скорость разработки• Не поддавайтесь просто так на моду NoSQL
  46. 46. Используйте хорошоизученные инструменты“Психологическая” популярность NoSQL:• marketing hype• мало знаний в области SQL: ACID, CAP, 3 НФ, транзакции• пытается сделать вид, что БД-специалист не нужен
  47. 47. Используйте хорошоизученные инструменты“Психологическая” популярность NoSQL:Идеальная БД для программиста• хранит объекты классов приложения (сериализация)• работает быстро (чтобы можно было похвастаться друзьям)• обо всем остальном заботится сама
  48. 48. Используйте хорошоизученные инструменты“Психологическая” популярность NoSQL:Выбор БД• техн. менеджмент спускает вопрос на тормозах, хотя это егозадача• БД выбирает тот самый программист• Выбираете NoSQL — понимайте, почему вы это делаетеК. О. предупреждает: так бывает далеко невсегда
  49. 49. Используйте хорошоизученные инструментыNoSQL:− запись в один поток− memory-mapped files, IO scheduling не для БД− один индекс на запрос− не очень гибкий шардинг− производительность тюнится только на уровне ОС− нет атомарности на уровне одного запроса− иногда скудный мониторинг, статистика
  50. 50. Используйте хорошоизученные инструментыNoSQL:− зачастую приходится писать кучу довольно скучного кода науровне приложения+ чаще всего быстрее SQL-баз+ проще развертывать, особенно шардинг+ нет схемы, ALTER TABLE забыто, как страшный сон
  51. 51. Используйте хорошоизученные инструментыSQL:− медленнее− сложнее(−) много каверзных настроек− в редких случаях непредсказуемо работает(−) позволяет писать медленные/плохие запросы
  52. 52. Используйте хорошоизученные инструментыSQL:+ более популярно, язык у всех на 80% совпадает+ хорошо изучено, стабильно+ оптимизировано хранение данных+ куча рычагов оптимизации+ constraintы, триггеры, хранимые процедуры+ ACID+ B-Tree, R-Tree, GIN, GIST, hash-индексы
  53. 53. Используйте хорошоизученные инструментыSQL:(+) Joinы, которые зло, но иногда выручают+ очень навороченный оптимизатор запросов+ параллельное исполнение (под)запросов+ многоуровневое кеширование+ статистика, мониторинг+ можно писать сложные запросы, не перенося логику в кодприложения
  54. 54. EVERYBODY LIESВыводов нет, думайте своей головой!
  55. 55. Вопросы?Аверин Сергейtwitter.com/ryba_xeks@averin.ruaverin.ru/slides/We’re hiring!
  1. ¿Le ha llamado la atención una diapositiva en particular?

    Recortar diapositivas es una manera útil de recopilar información importante para consultarla más tarde.

×