![Agenda
[Big]Data Source: when it becomes Big?
What cluster is? Horizontal and vertical scaling
[Big]Data Storage challenges
Disadvantages
NoSQL = Not only SQL
Most popular and trendy](https://image.slidesharecdn.com/bigdatastorages-161104133033/85/Tatyana-Matvienko-Senior-Java-Developer-Big-data-storages-2-320.jpg)
Tatyana Matvienko,Senior Java Developer, Big data storages
- 2. Agenda [Big]Data Source: when it becomes Big? What cluster is? Horizontal and vertical scaling [Big]Data Storage challenges Disadvantages NoSQL = Not only SQL Most popular and trendy
- 3. Big Data Storage Concepts Only stores facts (events), doesn’t analyze it Immutable Time series data (based on timestamps and, maybe, origin) Store everything, delete nothing Where: Messages (email, twitter), social networks, Sensor data (IoT), Log files, Locations
- 4. Cluster. Horizontal and vertical scaling What cluster is? Load balancer Communication: master/slave architecture Fault tolerance and replication factor
- 5. Size (keep and search huge amount of data) Speed (data acquisition, data search) Availability (fault tolerance, partition tolerance) Big Data Storage Challenges
- 6. Disadvantages of Big Data Storages No transactions (ACID) Less mature Big variety of concepts, lack of standardization No BI or analytics in queries Administration
- 9. Storages: Key-Value Examples: Redis, DynamoDB, MemcacheDB, Riak KV, Aerospike, OrientDB
- 10. Storages: Document oriented Examples: Apache CouchDB, Couchbase, MongoDB
- 11. Storages: Graphs Examples: Allegro, Neo4J, OrientDB, Titan
- 12. Storages: Column based Examples: Cassandra, HBase, Accumulo, Vertica
- 13. Why Cassandra?
- 14. Apache Cassandra: basics Masterless architecture with read/write anywhere design All nodes are the same No single point of failure Zone support Linear scalability CQL - cassandra query language Availability and Partition Tolerance but Eventual Consistency
- 17. Data modeling
- 19. Demo
Editor's Notes
- #4: Materialized view, functions, procedures and triggers в RDBMS и что от этого ушли (пример про Oracle и финансовый отчет) Отказ от UPDATE в пользу INSERT за счет обновленного таймстемпа В силу предыдущего пункта данные принято называть time series Т.к. аналитика происходит за пределами БД (batch jobs), то желательно ничего не удалять, т.к. если в наших джобах будут какие-то ошибки или проблемы - мы всегда можем их прогнать снова и получить новые результаты Рассказать про основные источники time series данных
- #5: Определение Коммуникационные протоколы -> master/slave architecture Single point of failure Распределение данных по кластеру, отказоустойчивость и репликация
- #6: Напоминание про CAP теорему ++ Меня потом спрашивали после лекции, Нужно еще раз пояснить, что это не догма, а скорее важный принцип о котором не следует забывать Трактовать тот же Consistency можно по разному
- #7: Проговорить традиционное понятие транзакции, расшифровать ACID Пройтись по пунктам: атомарность, консистентность, изолированность, доступность (пример: перевод денег на счет) Big Data storages появились относительно недавно, по сравнению с RDBMS Большое кол-во концепций и реализаций для разных задач Нормальные формы БД в RDBMS, здесь их нет, для аналитики вам нужны другие компоненты (а значит и их изучение, финансы на запуск и администрирование) Администрирование кластера само по себе более сложная вещь
- #8: S3 - web service, HDFS - software S3 provides eventual consistency (read-after-write) S3 communication: REST and SOAP S3 replication: you don’t control it, but you can enable cross-region replication HDFS - master-slave architecture (Namenodes, datanodes) HDFS: files splitted into parts - blocks HDFS: automatic recovery Adding nodes to cluster is ok, but deleting is a challenge
- #9: Здесь рассказать, почему sql запросы невозможно выполнять на NoSQL DBs (расшифровать понятие, пройтись по UPDATE, DELETE, COMMIT, ROLLBACK для примера)
- #10: Здесь сказать про кеш на примере Redis: Open source In memory (Redis holds its database entirely in memory, using the disk only for persistence) Scalable All the Redis operations are atomic Rich set of data types
- #11: Пример: MongoDB JSON-based documents (set of key-value pairs) Have dynamic schema Supports indexing and aggregation queries
- #16: Нет смысла хранить все данные на каждом из узлов Как распределить их по кластеру, Hash Ring Вопрос сохранности данных: репликация
- #17: Репликация асинхронна Протокол общения между нодам - Gossip Каждая нода может обрабатывать запросы. Нода, на которую пришел запрос, является координатором этого запроса Hinted handoff - если нода отпала, то какое-то время информация, которую ей нужно было передать, хранится и ждет, пока нода снова появится
- #18: Partition key Clustering column Ordering