Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

134 views

Published on

Выбор хранилища данных — сложная задача, с которой часто сталкиваются разработчики. Чаще всего результат этого выбора — это компромисс. Я расскажу о собственном опыте, набитых «шишках», рассмотрю важные, на мой взгляд, связанные с этой задачей проблемы.

Published in: Education
  • Be the first to comment

  • Be the first to like this

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

  1. 1. New Generation Data Protection Powered by Acronis AnyData Technology Распространенные ошибки применения баз данных Аверин Сергей, Acronis
  2. 2. ©2016 2 в цифрах 5 миллионов Более 5 млн обычных людей доверяют компании 
 хранить свои личные данные 500 000 Число корпоративных заказчиков из разных отраслей экономики 30 000 Обширная экосистема 
 из 30 000 бизнес-партнеров, 
 среди которых 300 — ОЕМ-партнеры 150 стран Продукты компании переведены на 18 языков, пользуются ими 
 в 150 странах мира 750 человек 750 сотрудников, 23 офиса по всему миру, среди сотрудников 
 компании более 350 инженеров высшего класса 45 наград Авторитетные издания не раз признавали продукты компании лучшими на рынке Домашние
 пользователи Корпоративные
 клиенты Партнеры География Сотрудники Признание
  3. 3. 8 советов
 про базы данных
  4. 4. 1) Масштабирование
  5. 5. ©2016 5 Масштабирование 1) С первых дней тратим кучу сил и времени на «готовность» к highload, большому масштабированию 2) Тратим большие ресурсы без быстрой отдачи 3) Сложные вопросы не рассматриваются по причине того, что мало опыта или проблемы еще не понятны
  6. 6. ©2016 6 Масштабирование Что имеем Что рассчитываем получить
  7. 7. ©2016 7 Масштабирование Способ масштабирования
  8. 8. ©2016 8 Масштабирование 1) “Серебряной пули” масштабирования нет 2) Проблемы будут уникальными для вашего проекта 3) Понадобится творческое решение 4) И многое придется переделывать
  9. 9. ©2016 9 Масштабирование 1) Для стартапа главными ценностями являются 
 быстрый старт и дешевизна изменений 2) Начните с простых, быстрых 
 и несложных решений «по рецепту» 3) Клиенты → опыт → понимание, какая архитектура нужна К. О. предупреждает: истиной для 100% случаев не является
  10. 10. 2) Отказоустойчивость
  11. 11. ©2016 11 Отказоустойчивость 1) При проектировании архитектуры проблемы нижних 
 уровней во внимание не принимаются 2) Железо, человеческий фактор, внешние риски и т. д. 3) Взаимосвязанность сбоев 4) В рамках одного сервера на практике не бывает
  12. 12. ©2016 12 Отказоустойчивость Как это сделано «у больших», на примере пользовательских данных: Выделенные БД-серверы ▪ проверенного вендора ▪ резервирование по питанию ▪ RAID 1+0
  13. 13. ©2016 13 Отказоустойчивость Как это сделано «у больших», на примере пользовательских данных: Софт ▪ фаервол ▪ Percona Server ▪ разные права доступа ▪ chroot-окружение
  14. 14. ©2016 14 Отказоустойчивость Как это сделано «у больших», на примере пользовательских данных: Архитектура ▪ запись в транзакции, на один сервер ▪ синхронизация с другим ДЦ
 через общую очередь
  15. 15. 3) БД c запасом на вырост
  16. 16. ©2016 16 БД c запасом на вырост 1) Выбирается БД без большого запаса фич,
 которые могут понадобиться в будущем 2) Ни один стартап не становился огромным в один день 3) Узкоспециализированные БД → теряется гибкость 4) NoSQL → нет возможности делать сложные вещи 
 худо-бедно, но ценой малых затрат на кодирование
  17. 17. 4) БД – хранилище событий
  18. 18. ©2016 18 БД — хранилище событий Распространенные use case’ы: ▪ события, порожденные транзакциями ▪ события, которые должны надежно доставляться ▪ события, которые можно потерять Использование БД как хранилища событий 
 чаще всего оправдано только ленью
  19. 19. ©2016 19 БД — хранилище событий Cпециализированный движок — 
 RabbitMQ, Kestrel, Scribe, Logstash и даже Redis: ▪ скорость ▪ простота ▪ фичи ▪ масштабируемость
  20. 20. ©2016 20 БД — хранилище событий При больших объемах советую Scribe: ✓ своя обертка с агрегацией данных, вставкой в БД ✓ меньше сетевых соединений ✓ передаем данные между ДЦ ✓ гибкие настройки ✓ при сбоях сохраняет данные локально ✓ очень быстрый
  21. 21. ©2016 21 Старые песни
 о главном
  22. 22. 5) Поиск
  23. 23. ©2016 23 Поиск ✓ Либо быстро, просто, плохо ✓ Либо используем бесплатный движок — 
 Sphinx, Solr, Lucene/ElasticSearch
  24. 24. ©2016 24 Поиск 99% случаев — быстро, просто, плохо: SELECT `id`, `body` FROM `entries` 
 WHERE `body` LIKE '%one%' SELECT `id`, `body` FROM `entries` WHERE `body` RLIKE '[[:<:]]one[[:>:]]' www.slideshare.net/billkarwin/practical-full-text-search-with-my-sql
  25. 25. ©2016 25 Поиск 99% случаев — быстро, просто, плохо: Some people, when confronted with a problem, think
 “I know, I’ll use regular expressions.” Now they have two problems. Jamie Zawinsky
  26. 26. ©2016 26 Поиск 99% случаев — быстро, просто, плохо: ▪ потом используем MySQL FULLTEXT Index ▪ для простых решений прекрасно 
 работает обратный индекс ▪ Но с полноценным поиском по тексту проблема в том, что просто плохо ищет =) ▪ а также: мало фич, медленно, хуже масштабируется
  27. 27. ©2016 27 Поиск 99% случаев — быстро, просто, плохо: ▪ а для каких-то задач просто неприменимо www.percona.com/files/presentations/opensql2008_sphinx.pdf Тест Percona: Индекс по всем статьям Википедии.
 2,5 млн записей, 15 Гб текста на одном сервере Sphinx: 20 минут MySQL: админ уснул через 6 часов, так и не дождавшись
  28. 28. ©2016 28 Поиск Используйте специализированный софт: ▪ проще в разработке ▪ быстрее ▪ больше возможностей ▪ масштабируется ▪ а главное, лучше ищет
  29. 29. 6) Сильная consistency
  30. 30. ©2016 30 Сильная consistency ✓ Не всегда нужна в вебе ✓ Часто сложно достижима ✓ Особенно, когда данные в один сервер не помещаются и надо что-то придумывать
  31. 31. ©2016 31 Сильная consistency ✓ Eventual consistency рулит ✓ Можно писать в базу выборочно или писать агрегированные данные, не нагружая БД ✓ Денормализация может дать большой прирост производительности ✓ Важно знать меру, и что мы теряем,
 а что получаем
  32. 32. ©2016 32 Сильная consistency Чтобы не получилось так: SQL DB = ‘A consistent transactional datastore with schema guarantees that uses relational algebra to access normalized tables.’
  33. 33. ©2016 33 Сильная consistency Чтобы не получилось так: + добавляем slave — репликация + мемкеш + добавляем еще slave’ов — репликация репликации + шардинг + один столбец на таблицу, храним 
 в нем сериализованный объект
  34. 34. ©2016 34 Сильная consistency Чтобы не получилось так: SQL DB = ‘A consistent transactional datastore with schema guarantees that uses relational algebra to access normalized tables.’ Много данных, кривые руки = datastore with access to data, лучше и не скажешь www.youtube.com/watch?v=zAbFRiyT3LU
  35. 35. 7) Используйте хорошо изученные инструменты
  36. 36. ©2016 36 Используйте хорошо
 ✓ Неизвестность → опасность ✓ Выше скорость разработки ✓ Не поддавайтесь просто так на моду NoSQL
  37. 37. ©2016 37 Используйте хорошо
 “Психологическая” популярность NoSQL: ▪ marketing hype ▪ мало знаний в области SQL: ACID, CAP, 3 НФ, транзакции ▪ пытается сделать вид, 
 что БД-специалист не нужен
  38. 38. ©2016 38 Используйте хорошо
 “Психологическая” популярность NoSQL: Идеальная БД для программиста ▪ хранит объекты классов приложения (сериализация) ▪ работает быстро (чтобы можно было похвастаться друзьям) ▪ обо всем остальном заботится сама
  39. 39. ©2016 39 Используйте хорошо
 “Психологическая” популярность NoSQL: Выбор БД ▪ техн. менеджмент спускает вопрос “на тормозах”, 
 хотя это его задача ▪ БД выбирает тот самый программист ▪ Выбираете NoSQL — понимайте, почему вы это делаете К. О. предупреждает: так бывает далеко не всегда
  40. 40. ©2016 40 Используйте хорошо
 NoSQL: – запись в один поток – memory-mapped files, IO scheduling не для БД – один индекс на запрос – не очень гибкий шардинг – производительность тюнится только на уровне ОС – нет атомарности на уровне одного запроса – иногда скудный мониторинг, статистика
  41. 41. ©2016 41 Используйте хорошо
 NoSQL: − зачастую приходится писать кучу довольно 
 скучного кода на уровне приложения + чаще всего быстрее SQL-баз + проще развертывать, особенно шардинг + нет схемы, ALTER TABLE забыто, как страшный сон
  42. 42. ©2016 42 Используйте хорошо
 SQL: − медленнее − сложнее (−) много каверзных настроек − в редких случаях непредсказуемо работает (−) позволяет писать медленные/плохие запросы
  43. 43. ©2016 43 Используйте хорошо
 SQL: + более популярно, язык у всех на 80% совпадает + хорошо изучено, стабильно + оптимизировано хранение данных + куча рычагов оптимизации + constraint'ы, триггеры, хранимые процедуры + ACID + B-Tree, R-Tree, GIN, GIST, hash-индексы
  44. 44. ©2016 44 Используйте хорошо
 SQL: (+) Join'ы, которые зло, но иногда выручают + очень навороченный оптимизатор запросов + параллельное исполнение (под)запросов + многоуровневое кеширование + статистика, мониторинг + можно писать сложные запросы,
 не перенося логику в код приложения
  45. 45. 8) Как не завалить SQL БД
  46. 46. ©2016 46 Как не завалить SQL БД ▪ Не использовать JOIN’ы ▪ Не делать таблицы > 10 000 000 записей ▪ Не делать кучу индексов ▪ Не делать часто исполняемых сложных запросов ▪ Кешировать редко меняющиеся данные ▪ Не использовать БД как хранилище файлов ▪ Не использовать хранимые процедуры
  47. 47. ©2016 47 EVERYBODY LIES Выводов нет, думайте своей головой!
  48. 48. ©2016 48 Вопросы? Аверин Сергей
 twitter.com/ryba_xek
 s@averin.ru
 averin.ru/slides/ facebook.com/ryba.xek
  49. 49. acronis.com blog.acronis.com twitter.com/acronis facebook.com/acronis New Generation Data Protection Powered by Acronis AnyData Technology

×