3. Agenda
#1: Academic issues: Shard, HP, VP
#2: What is Volt DB? Why ! VoltDB?
#3: Real VoltDB application
#4: Tips and Tweaks: you are not
supposed to do that at all
4. Agenda
#1: Academic issues: Shard, HP, VP
#2: What is Volt DB? Why ! Volt DB?
#3: Simple Volt DB application
#4: Tips and Tweaks: you are not
supposed to do that at all
5. Academic issues
What is:
● Shard, Horizontal Partitioning
● ACID complaint DBMS
● In-memory and real time DB
6. Academic issues
What is:
● Shard, Horizontal Partitioning
● ACID compliant DBMS
● In-memory and real time DB
15. Academic issues
What is:
● Shard, Horizontal Partitioning
● ACID compliant DBMS
● In-memory and real time database
16. In-memory/real time
database
● Storage is option, not requirement
● Key value? No!
● Data access is cheap (no I/O)
● Real time processing
17. Agenda
#1: Academic issues: Shard,HP,VP
#2: What is Volt DB? Why?! Volt DB?
#3: Simple Volt DB application
#4: Tips and Tweaks: you are not
supposed to do that at all
32. Volt DB tools
● csvloader — can load data from CSV
file
● exporttofile — exports to CSV/TSV file
● sqlcmd — mysql like client
● voltadmin - administrative functions
● voltdb — catalog (DB) management
and server
35. Agenda
#1: Academic issues: Shard,HP,VP
#2: What is Volt DB? Why?! Volt DB?
#3: Simple Volt DB application(Super Chat)
#4: Tips and Tweaks: you are not
supposed to do that at all
37. DB Schema file
1: CREATE TABLE messages (
uid BIGINT NOT NULL,
nick VARCHAR(64) NOT NULL,
ip VARCHAR(16) NOT NULL,
text VARCHAR(1024)
);
38. DB Schema file
1: CREATE TABLE messages (
uid BIGINT NOT NULL,
nick VARCHAR(64) NOT NULL,
ip VARCHAR(16) NOT NULL,
text VARCHAR(1024)
);
2: CREATE INDEX messages_idx ON messages (nick, ip);
39. DB Schema file
1: CREATE TABLE messages (
uid BIGINT NOT NULL,
nick VARCHAR(64) NOT NULL,
ip VARCHAR(16) NOT NULL,
text VARCHAR(1024)
);
2: CREATE INDEX messages_idx ON messages (nick, ip);
3: PARTITION TABLE messages ON COLUMN nick;
40. DB Schema file
1: CREATE TABLE messages (
uid BIGINT NOT NULL,
nick VARCHAR(64) NOT NULL,
ip VARCHAR(16) NOT NULL,
text VARCHAR(1024)
);
2: CREATE INDEX messages_idx ON messages (nick, ip);
3: PARTITION TABLE messages ON COLUMN nick;
4: CREATE PROCEDURE FROM CLASS vposter.procedures.AddMessage;
41. DB Schema file
1: CREATE TABLE messages (
uid BIGINT NOT NULL,
nick VARCHAR(64) NOT NULL,
ip VARCHAR(16) NOT NULL,
text VARCHAR(1024)
);
2: CREATE INDEX messages_idx ON messages (nick, ip);
3: PARTITION TABLE messages ON COLUMN nick;
4: CREATE PROCEDURE FROM CLASS vposter.procedures.AddMessage;
5: PARTITION PROCEDURE AddMessage ON TABLE messages COLUMN
nick;
42. DB Schema file
1: CREATE TABLE messages (
uid BIGINT NOT NULL,
nick VARCHAR(64) NOT NULL,
ip VARCHAR(16) NOT NULL,
text VARCHAR(1024)
);
2: CREATE INDEX messages_idx ON messages (nick, ip);
3: PARTITION TABLE messages ON COLUMN nick;
4: CREATE PROCEDURE FROM CLASS vposter.procedures.AddMessage;
5: PARTITION PROCEDURE AddMessage ON TABLE messages COLUMN
nick;
44. Putting All Together
sh $ javac -cp "$CLASS_PATH:/opt/voltdb-3.7/voltdb/*"
java/vposter/procedures/AddMessage.java
sh$ voltdb compile --classpath=./java/ -o voltdb-catalog.jar
/path/to/schema/schema-ddl.sql
# Finaly, run the server
sh$ voltdb create catalog voltdb-catalog.jar
46. Agenda
#1: Academic issues: Shard,HP,VP
#2: What is Volt DB? Why?! Volt DB?
#3: Simple Volt DB application(Super Chat)
#4: Tips and Tweaks: you are not
supposed to do that at all
47. Tips and Tweaks
● Java Stored procedures
● Schema file: restrictions and syntax
● Client code vs Server code
● TPS: Performance Testing
● Deployment configuration
48. Java Stored procedures
● Minimize hard math. calculations, I.e. let's
client do what it needs
● Minimize SQL queue, i.e. usage of
lists/arrays as parameters is real
optimization
● Do not return huge chunk of data
● To Throw or Not To Throw
● Use statuses (application and response)
49. Schema file: restrictions and
syntax
● Use comments
● Renaming columns/tables in DDL
● Constraint LIMIT PARTITION ROWS
● Standard constraints
● Views as mechanism of aggregation
50. Client code vs Server code
● Let server aggregate data, let client
process data
● Table-Of-Tables
● Optimize Insertions
● Why SELECT * requests are
dangerous?
53. References
l http://odbms.org/download/VoltDBTechnicalOverview.pdf
l http://www.mysqlperformanceblog.com/2011/02/28/is-voltdb-really-as-scalable-as-they-claim/
l http://voltdb.com
l http://techledger.wordpress.com/2011/07/08/voltdb-faq/
l http://highscalability.com/blog/2010/6/28/voltdb-decapitates-six-sql-urban-myths-and-delivers-internet.html
l http://www.perfdynamics.com/Manifesto/USLscalability.html#tth_sEc1
l git@github.com:vtorshyn/voltdb-shardit-src.git
Editor's Notes
Усім привіт!
Дякую що знайшли час відвідати мою доповідь. Мене звати Віталій Торшин. Працюю на проекті openet, C/C++ розробником. Я розумію що ваш час дорогоцінний, тому давайте не будем гаяти його.
Отже, доповідь стосується декількох аспектів розробки програмного забезпечення і від вас очікуються мінімальні, проте знання, архітектури та розробки ПЗ, для прикладу - клієнт сервер. Сьогодні ми не будемо глибоко занурюватись у теорію, проте ми розглянемо декілька ключових пов’язанних саме із базами данних (RDBMS).
В дійсності, наша команда вже має успішний досвід використання voltdb на реальному проекті у галузі телеком.
Одна із вимог щодо швидкодії під час розробки усієї системи була TPS > 250 000.
Що нам і вдалось отримати навіть із кластером у одну ноду.
Доповідь поділена на 4 розділи таким чином, щоб ми мали змогу пригадати, що таке Shard, HP,VP;
Зрозуміти що це таке voltdb, і чому варто зупинитись на voltdb а не на Mongo чи MySQL; звичайно чи підійде voltdb для вашого проекту.
У наступній частині ми розглянемо простий проте повністю робочий приклад роботи із voltdb на мові C++ із використанням клієнта С++.
Остання частина присвячена різним хитростям та підводним каменям повязаним із використанням voltdb.
Bla-bla
Давайте розглянемо приклад із реального світу.
Я звернувся за допомогою до торговців фруктами, зокрема яблуками Джамшута та Чіпко.
Джамшут вже досить довго у цьому бізнесі, і він розуміється як позбавитись черги біля свого прилавку.
Проте Чіпко, ярий противник нових методів продаж. Його не хвилюють черги біля прилавків.
VP – row splitting. Виносять колонки навіть якщо таблиця нормалізована
Отже на данному етапі можна скористатись нормалізацією, тобто піддати логічну модель данних процессу реструктуризації бази данних аби уникнути надлишковості. Форми нормалізації знаходяться поза топіком цієї доповіді, та і у мережі є досить багато інформації щодо усіх 6 форм.
В основному ідея полягає у розділення інформації що знаходиться у рядку на окремі колонки (які можуть знаходитись як і у тій самій таблиці, так і у інших таблицях)
Horizontal partitioning splits one or more tables by row, usually within a single instance of a schema and a database server. It may offer an advantage by reducing index size (and thus search effort) provided that there is some obvious, robust, implicit way to identify in which table a particular row will be found, without first needing to search the index, e.g., the classic example of the 'CustomersEast' and 'CustomersWest' tables, where their zip code already indicates where they will be found.
Sharding goes beyond this: it partitions the problematic table(s) in the same way, but it does this across potentially multiple instances of the schema. The obvious advantage would be that search load for the large partitioned table can now be split across multiple servers (logical or physical), not just multiple indexes on the same logical server.
Splitting shards across multiple isolated instances requires more than simple horizontal partitioning. The hoped-for gains in efficiency would be lost, if querying the database required both instances to be queried, just to retrieve a simple dimension table. Beyond partitioning, sharding thus splits large partitionable tables across the servers, while smaller tables are replicated as complete units.
- Атомарність гарантує, що жодна транзакція не буде виконана частково. Будуть або виконані всі операції, що беруть участь у транзакції або не виконано жодної.
- Відповідно до цієї вимоги, система повинна знаходитись в узгодженому, несуперечливому стані до початку дії транзакції і по її завершенню. При цьому вона може знаходитись у неузгодженому стані у процесі виконання транзакції, проте ця неузгодженість завдяки іншим властивостям - атомарності та ізольованості - не буде видимою за межами транзакції.
-зольованість означає що ніякі проміжні зміни не будуть видимі за межами транзакції аж до її завершення
-Довговічність гарантує, що незалежно від інших проблем після відновлення роботоздатності системи результати завершених транзакцій будуть збережені. Іншими словами, якщо користувач отримав повідомлення про успішне завершення транзакції, то він може бути впевнений, що дані будуть збережені і відновлені у випадку збоїв.
Still, voltdb is not popular as MySQL or Oracle or even MongoDB.
Creators is Michael Stonebraker. First release in 2010.
Atomicity, Consistency, Isolation, Durability
Фактично кожна нода (шард) є незалежним. Тобто, якщо ляжуть усі ноди окрім однієї – вона залишеться повністю функціональною.
Звичайно немає жодних посилань на данні із однієї ноди до іншої, так само як із одного розділу до іншого.
claims to be 100 times faster than MySQL, up to 13 times faster than Cassandra, and 45 times faster than Oracle, with near-linear scaling.
Розподілене та серіалізоване виконання ріквестів.
Фактично VoltDB не має вимог до обєму ОЗУ чи дискового простору – розробник має сам визначати ці цифри. Єдина вимога – кількість розділів на одному сервері має відповідати кількості фізичних ядер процесора. Серцем voltdb є високо оптимізований С++ код, який використовує JNI для виконання сторед процедур.
Взагалі у волдб будь-яке виконання sql запиту (на з сторед процедури) автоматично є сторед процедурою, що робить автоматично транзакцією.
Значення K-factor або k-safety у конфігурації voltdb фактично відповідає кількості копій розділів у кластері. Іншими словами це є множник кількості реплік, тобто для прикладу у нас є 4 розділи на шарді, і при значені k-safety=1 кількість розділів вже буде 8, при 2 – 12 і тд.
Варто зазначити що використання значень більше а ніж 1 має бути обгрунтованим, так як у цьому випадку швидкодія буде суттєво нижчою.
Значення K-factor або k-safety у конфігурації voltdb фактично відповідає кількості копій розділів у кластері. Іншими словами це є множник кількості реплік, тобто для прикладу у нас є 4 розділи на шарді, і при значені k-safety=1 кількість розділів вже буде 8, при 2 – 12 і тд.
Варто зазначити що використання значень більше а ніж 1 має бути обгрунтованим, так як у цьому випадку швидкодія буде суттєво нижчою.