PB Scale with MarkLogic Server A talk by Nuno Job, - PowerPoint PPT Presentation

ACID ¡Transac,ons ¡at ¡the ¡ ¡ PB ¡Scale ¡with ¡MarkLogic ¡Server ¡ A ¡talk ¡by ¡Nuno ¡Job, ¡ Welcome ¡to ¡Berlin ¡Buzzwords ¡2011! ¡ @dscape | #bbuzz PB Scalable Transactions

portugal, new york, toronto, san francisco, london � 11 � 83 � 08 � 10 � 09 � H ¡E ¡L ¡L ¡O ¡ ¡ s i past. � ¡ e m a n ¡ y m Nuno � present. � stuff I like � @dscape �

foreseeable future. �

the idea Pre-defined Ad-hoc � search � engines � Structure ¡ ims � rdbms � dinosaurs � idms � are � fun! � Pre-defined Ad-hoc � (o0)—’,-- � � Queries ¡ relational � search � modern database � NoSQL � bloom � engine � ancestors � 00’s � 60’s � 80’s � 90’s � timeline timeline � @dscape | #bbuzz PB Scalable Transactions

a database for unstructured information also stores: � unstructured � text and binaries � c++ core � schema-less* � ~ pb scale � easy evolution. � xml or json. � features � acid, backups � replication, query � native search � language (xquery). � a database built � on a search engine? � !! � stop shredding your data � no tables, rows, columns � start storing data as is � thinkin’ documents � uris? looks like a filesystem � * they have this universal index thing. � an inverted index that is structure aware � @dscape | #bbuzz PB Scalable Transactions

� � application server single tier: � - no boundaries � XQuery: � between languages � dynamic, functional � - smaller stack � programming language � - king is dead! � long live the king! � features: � !! � stop exposing your database � start exposing your data � - easy geospatial � - http client � - facets � - alerting � - store applications � apps � in the database � marklogic � - url rewriting � api � apps � other dbs � apps � github.com/dscape/rewrite � ( for rails like routing, session later on ) � REST � @dscape | #bbuzz PB Scalable Transactions

� In ¡MarkLogic ¡we ¡were ¡thinkin’ ¡ ✓ Unstructured ¡Informa,on ¡ ¡ flexible � thinkin’ documents. � json or xml? � ✓ Mul,ple ¡TBs ¡to ¡PB ¡scale ¡ big � ✓ Sub-­‑second ¡response ¡,mes ¡ fast � ever wonder what � that lotus flower � ✓ Data ¡ immediately ¡durable ¡ ¡ realtime � video-clip is all � about? � ✓ Mix ¡of ¡complex ¡database ¡queries, ¡ � aler,ng, ¡full ¡text ¡search, ¡transforma,ons, ¡ love to talk � geospa,al, ¡and ¡real ¡,me ¡analy,cs. ¡ about this �

� unstructured? ¡ To be great, be whole; � blank verse � Exclude nothing, � line � exaggerate nothing that is not you. � Be whole in everything. � Put all you are � Into the smallest thing you do. � So, in each lake, the moon shines � Because it blooms up above. � buttons � thread � Ricardo Reis, Odes � Wool � author � poem � silk � title � unstructured � relational � closet � closet �

universal ¡index ¡ universal index: � slides: � an inverted index that understands http://www.slideshare.net/cbiow/ structure, organization, and security � mark-logic-strangeloop-2010 � 123, ¡126, ¡130, ¡152, ¡… ¡ ¡ “berlin” ¡ 122, ¡125, ¡126, ¡130, ¡… ¡ ¡ “buzzwords” ¡ “fast” ¡ 123, ¡126, ¡130, ¡142, ¡… ¡ 123, ¡130, ¡131, ¡135, ¡… ¡ ¡ “nosql” ¡ Document ¡ “hadoop” ¡ 125, ¡131, ¡167, ¡212, ¡… ¡ References ¡ <preso> ¡ 122, ¡126, ¡130, ¡131, ¡… ¡ 126, ¡130 ¡ 126, ¡130, ¡131, ¡167, ¡… ¡ <preso> ¡/ ¡<,tle> ¡ <y>2011</y> ¡ 122, ¡126, ¡130, ¡131, ¡… ¡ pub ¡ Like learning how � nosql ¡ ¡ ¡ ¡ ¡ ¡ ¡ relational worked in � Editor ¡Read ¡ ¡ ¡ ¡ ¡ ¡ ¡ the 80s ¡

“ It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change. ” � - Charles Darwin

ACID Helps Atomicity Either all operations of the transaction - Easy to reason about are correctly executed or none is. ¡ data � ¡ - Guaranteed persistent � Consistency state ¡ Database will remain in a consistent ¡ state after the transaction commits. ¡ ¡ Hurts Isolation In a concurrent transactional system - Hard to scale transactions are unaware of each other. ¡ horizontally � ¡ - Hard to assure high Durability availability ¡ After a transaction completes, changes ¡ persist even if the system fails. � ¡ @dscape | #bbuzz PB Scalable Transactions

CAP mysql ¡ Consistency Each client always has the same view of the data. ¡ ¡ Availability All clients can always read and write. ¡ ¡ redis ¡ riak ¡ Partition Tolerance System works well across physical network partitions. � Pick Two! ¡ credit: blog.nahurst.com � /visual-guide-to-nosql-systems ¡ @dscape | #bbuzz PB Scalable Transactions

“ It’s naive to explain NoSQL with CAP... for x tending to infinite it's like stating that in the world there are just 3 databases. ” � - Salvatore Sanfillipo, @antirez

“ There is a magic bullet! � It's called relaxing the requirements. ” � - Evan Weaver, @evan

� � � � * ¡ scaling an inverted index journaled! durability ++ ¡ memory disk Ingestion is limited to a size where indexes are manageable � On query both in memory and on disk stands behave the same -> transparent to the developer � Means: � Log-Structured Fast ingestion with Merge-Tree � transactions! � (LSM-Tree) � Zero-latency ingestion and Indexing � @dscape | #bbuzz PB Scalable Transactions

“ You cannot take a car, grow it 10 times and expect to get a mining truck. ” � - Ivan Pepelnjak, @ioshints

divide and conquer level of abstraction: ease of use � even distribution � database ¡ across nodes � stand � a group of trees � makes sense to � par,,on 1 par,,on 2 par,,on 3 ¡ ¡ ¡ have indexes in � the same stand � @dscape | #bbuzz PB Scalable Transactions

shared nothing cluster E ¡Host ¡ 1 ¡ E ¡Host ¡ 2 ¡ E ¡Host ¡ n ¡ D ¡Host ¡ 4 ¡ D ¡Host ¡ 5 ¡ D ¡Host ¡ 6 ¡ D ¡Host ¡ k ¡ par--on 1 ¡ par--on 2 ¡ par--on 3 ¡ par--on 4 ¡ par--on m ¡ @dscape | #bbuzz PB Scalable Transactions

� � MVCC Append only database � High Throughput � Queries don’t require locks � Queries and Updates do � not conflict � ACID � Cluster consistency: 2-phase commit ¡ @dscape | #bbuzz PB Scalable Transactions

mvcc queries never lock! � Series ¡1 ¡ delete ¡ eric.json ¡ replace ¡node ¡ mary.json ¡ maria.json ¡ insert ¡ john.json ¡ query ¡ System ¡ 0 ¡ 5 ¡ 10 ¡ 15 ¡ 20 ¡ 25 ¡ ,mestamp ¡ @dscape | #bbuzz PB Scalable Transactions

How does the 2-phase commit work? insert-child insert “/foo.json”, { “foo”: “” } delete “foo.json” Journal A “foo.json”.foo, insert “/bar.json”, { “bar”: “” } delete “bar.json” Insert ¡fragment ¡123 ¡“/foo.json” ¡ “stuff” Distributed ¡Begin, ¡A ¡added(123), ¡B ¡added(234) ¡ Shard A Commit, ¡,mestamp ¡1, ¡added ¡(123) ¡ Distributed ¡End ¡ ID ¡ ✔ ¡ ✗ ¡ URI ¡ Insert ¡fragment ¡345 ¡“/foo.json” ¡ /foo.json � Commit, ¡,mestamp ¡2, ¡added ¡(345), ¡deleted ¡(123) ¡ 123 � 1 � 2 Distributed ¡Begin, ¡A ¡added(123), ¡B ¡added(234) ¡ 345 � 2 3 /foo.json � Commit, ¡,mestamp ¡3, ¡deleted ¡(34567) ¡ Distributed ¡End ¡ Shard B Journal B Insert ¡fragment ¡234 ¡“/bar.json” ¡ ID ¡ ✔ ¡ ✗ ¡ URI ¡ Prepare ¡ Commit, ¡added ¡(123) ¡ 234 � 1 � 3 /bar.json � Prepare ¡ Commit, ¡deleted ¡(234) ¡ doesn’t lock documents, locks uris � @dscape | #bbuzz PB Scalable Transactions

developer.marklogic.com awesome project btw… � 365q.ca ¡

“ You have database problem. You research blog and HN. You start use NoSQL product. Now you not know anymore if you have problem. ” � - Devops BORAT, @devops_borat

Questions? @dscape @dscape | #bbuzz PB Scalable Transactions