LogicBloX P lat f o r m and L anguage : a T uto r ial Todd J. - - PowerPoint PPT Presentation

SLIDE 1

Molham Aref

LogicBloX

Platform and Language: a Tutorial

Todd ¡J. ¡Green ¡

Molham ¡Aref ¡ ¡ ¡Shan ¡Shan ¡Huang ¡ Grigoris ¡Karvounarakis ¡ ¡Todd ¡Veldhuizen ¡

Datalog ¡2.0 ¡Vienna ¡ September ¡12, ¡2012 ¡

SLIDE 2

• 1. Vision ¡
• 2. Language ¡
• 3. RunHme ¡

SLIDE 3

en•ter•prise soft•ware

\ˈen-tə(r)-ˌprīz ˈsȯft-ˌwer\

¡

• SoIware ¡somebody ¡pays ¡you ¡to ¡use ¡

– AccounHng, ¡sales, ¡supply-­‑chain, ¡customer-­‑relaHonship ¡ management, ¡etc... ¡

• Expensive ¡ ¡ ¡

– $244B ¡(’10) ¡-­‑> ¡$267B ¡(’11) ¡-­‑> ¡$288B ¡(’12) ¡

• Doesn’t ¡work ¡

– Most ¡enterprise ¡decisions ¡sHll ¡made ¡with ¡Excel ¡

3

SLIDE 4

Enterprise ¡Decision ¡AutomaHon ¡Nightmare ¡

4

Bookkeeping ¡ BI ¡ Planning ¡ App ¡ View ¡ Data ¡

PRESENT PAST FUTURE

SLIDE 5

BI ¡ App ¡ Bookkeeping ¡ Planning ¡ View ¡ Data ¡

Enterprise ¡Decision ¡AutomaHon ¡Nightmare ¡

5

SLIDE 6

BI ¡ App ¡ BI ¡App ¡ Server ¡ Bookkeeping ¡ Planning ¡ View ¡ Data ¡ OLTP ¡ ¡ Database ¡ Applica.on ¡ Server ¡ User ¡ ¡ Interface ¡ OLAP ¡ Database ¡ User ¡ ¡ Interface ¡ Planning ¡ Database ¡ User ¡ ¡ Interface ¡

Enterprise ¡Decision ¡AutomaHon ¡Nightmare ¡

6

SLIDE 7

BI ¡ App ¡ BI ¡App ¡ Server ¡ Bookkeeping ¡ Planning ¡ View ¡ Data ¡ OLTP ¡ ¡ Database ¡ Applica.on ¡ Server ¡ User ¡ ¡ Interface ¡ OLAP ¡ Database ¡ User ¡ ¡ Interface ¡ Planning ¡ Database ¡ User ¡ ¡ Interface ¡

Enterprise ¡Decision ¡AutomaHon ¡Nightmare ¡

7

ETL ETL

SLIDE 8

IT ¡Landscape ¡– ¡Supply ¡Chain ¡(2% ¡of ¡footprint) ¡

<Current> Retek RMS (v9) <Current> I01 - Receiving <Current> I03 - RTV <Current> I02 - Transfer <Current> I04 – Home Delivery <Current> I05 – Inventory <Current> Allocator <Current> Anti-Dealer <Current> Cambell- Staffworks <Current> Cambell Time & Attendance <Current> Dynamic Backstock- tool <Current> E3 <Current> Ladder <Current> I06 WMS <Current> I09 – Cycle Counts <Current> I10 – Cycle Physical Inventory <Current> I13 – Auto Replenishment <Current> I35 – Early Warning System <Current> Star-In-Home <Current> Star Repair Transfer Shipment Manifest Inventory Adjustment PO Receipts Transfer Receipts Cycle Counts Transfer ASN Inventory Availability Inventory Adjustment Optimized Delivery Route Inventory Adjustments Transfer RTV Request Transfer RTV Errors Transfer Receipts PO Receipts <Current> AAS Transfer Receipts Shipment Manifest Cycle Counts Transfer ASN PO Receipts Transfer <Current> I07 – Purchase Orders Inventory Adjustments Inventory Adjustments Purchase Orders RMS <Current> <Current> I01 - Scheduling PO Dates Purchase Orders Receipt Schedule Receipt Schedule PO Receipts Allocations Store Transfers Purchase Orders Yantra OMS <Target> D W <Current> VPM Purchase Orders PO Receipts Shipment Manifest Inventory Adjustment Transfers Location & SKU Location & SKU RTV Transfers Store to DC Inventory On-Hand Inventory Purchase Orders Forecast Active SKUs Active Assortment Vendors Purchase Orders PO Acknowledgement <Current> Customer Order Mgmt (CO server) Transfer Customer Order Forecast <Current> Dataflex PO and PO Receipts <Current> Mainframe Inventory Inventory ASN <Target> EXETER <Target> i2 TMS <Target> Texlon Delivery Schedule Intl Shipment Status ASN Receipts Schedules ASN’s Receipts PO’s Analytics <Target> RSS <Target> Rapistan Shipment Scan Information <Target> VST <Target> RIMMS <Current> Bridgepoint <Current> Auto Destination <Current> Electronic Subscription Capture Fulfill Demand Current Information Exchange Genco Portal <Current> i2 SCEM <Current> DDS Franklin

SLIDE 9

(Not ¡that ¡we ¡advocate ¡overthrowing ¡capitalist ¡states ¡and ¡ replacing ¡them ¡with ¡Stalinist ¡regimes, ¡but…) ¡

9

“If ¡you ¡tremble ¡with ¡indignaHon ¡at ¡ every ¡injusHce, ¡then ¡you ¡are ¡a ¡ comrade ¡of ¡mine.” ¡ Che ¡Guevara ¡

SLIDE 10

The ¡LogicBlox ¡Vision ¡

• Forget ¡the ¡hairball. ¡ ¡The ¡hairball ¡is ¡dumb. ¡
• Minimize ¡moving ¡parts, ¡minimize ¡glue ¡

– Unify ¡the ¡programming ¡model ¡and ¡ ¡ – Unify ¡the ¡execuHon ¡environment ¡ – Simplify ¡aggressively ¡

• FoundaHon: ¡(extended) ¡Datalog ¡

10

SLIDE 11

Bookkeeping ¡ BI ¡ Planning ¡ App ¡ View ¡ Data ¡ OLTP ¡ ¡ Database ¡ ApplicaHon ¡ Server ¡ User ¡ ¡ Interface ¡ OLAP ¡ Database ¡ BI ¡App ¡ Server ¡ User ¡ ¡ Interface ¡

The ¡LogicBlox ¡Vision ¡

11

Planning ¡ Database ¡ Planning ¡App ¡ Server ¡ User ¡ ¡ Interface ¡

SLIDE 12

Bookkeeping ¡ BI ¡ Planning ¡ App ¡ View ¡ Data ¡ OLAP ¡ Database ¡ BI ¡App ¡ Server ¡ User ¡ ¡ Interface ¡

The ¡LogicBlox ¡Vision ¡

12

Planning ¡ Database ¡ Planning ¡App ¡ Server ¡ User ¡ ¡ Interface ¡ LogicBlox ¡ language ¡ ¡ runHme ¡

SLIDE 13

Bookkeeping ¡ BI ¡ Planning ¡ App ¡ View ¡ Data ¡

The ¡LogicBlox ¡Vision ¡

13

Planning ¡ Database ¡ Planning ¡App ¡ Server ¡ User ¡ ¡ Interface ¡ LogicBlox ¡ language ¡ ¡ runHme ¡ LogicBlox ¡ language ¡ ¡ runHme ¡

SLIDE 14

Bookkeeping ¡ BI ¡ Planning ¡ App ¡ View ¡ Data ¡

The ¡LogicBlox ¡Vision ¡

14

LogicBlox ¡ language ¡ ¡ runHme ¡ LogicBlox ¡ language ¡ ¡ runHme ¡ LogicBlox ¡ language ¡ ¡ runHme ¡

SLIDE 15

BI ¡ View ¡ App ¡ Data ¡ Bookkeeping ¡ Planning ¡

The ¡LogicBlox ¡Vision ¡

15

LogicBlox ¡ language ¡ ¡ runHme ¡ Rendering ¡

SLIDE 16 16

are you

CRAZY?!?

(naive? delusional?)

SLIDE 17

Some ¡Clients ¡

Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡ Client ¡Logo ¡

SLIDE 18 18

“The ¡more ¡ambiHous ¡plan ¡may ¡have ¡ more ¡chances ¡of ¡success...” ¡ ¡ George ¡Pólya ¡

SLIDE 19

• 1. Vision ¡
• 2. Language ¡
• 3. RunHme ¡

SLIDE 20

Why ¡Datalog? ¡ ¡No ¡a ¡Priori ¡Bias ¡

• Usability ¡

– DeclaraHve ¡and ¡disorderly ¡ – Skinnable ¡– ¡give ¡people ¡the ¡syntax ¡they ¡like ¡

• Expressivity ¡

– Well-­‑understood ¡expressivity ¡with ¡“controllable” ¡power ¡

• Safety ¡

– Turing-­‑completeness ¡considered ¡harmful ¡ – ACID ¡transacHons ¡with ¡full ¡serializability ¡

• Performance ¡

– AutomaHc ¡opHmizaHon, ¡incremental ¡evaluaHon, ¡parallelizaHon ¡

• Elegance ¡

– SQL ¡lexer+parser: ¡>14,000 ¡LOC; ¡Blox ¡lexer+parser: ¡< ¡1000 ¡LOC ¡

• Very ¡large ¡body ¡of ¡mostly ¡un-­‑commercialized ¡research ¡

SLIDE 21

Core ¡Blox ¡Language: ¡ ¡ StaHcally-­‑Typed, ¡StraHfied ¡Datalog¬

21

/* ¡EDB ¡predicates ¡and ¡facts ¡*/ ¡ a(X) ¡-­‑> ¡string(X). ¡ b(X,Y) ¡-­‑> ¡string(X), ¡string(Y). ¡ a(“apple”). ¡ b(“apple”, ¡“banana”). ¡ ¡ /* ¡IDB ¡predicates ¡*/ ¡ c(X) ¡<-­‑ ¡a(X). ¡ c(Y) ¡<-­‑ ¡b(X,Y), ¡c(X), ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡!b(Y,X). ¡ int[8], ¡ uint[32], ¡ float[64], ¡ decimal[128], ¡ boolean, ¡ datetime, ¡ etc ¡

SLIDE 22

Blox: ¡Integrity ¡Constraints ¡

22

/* ¡An ¡EDB ¡predicate ¡foo ¡*/ ¡ foo(X,Y) ¡-­‑> ¡int[64](X), ¡datetime(Y). ¡ ¡ /* ¡A ¡constraint ¡stating ¡that ¡foo ¡is ¡

• functional. ¡ ¡(Unlike ¡types, ¡constraints ¡are ¡

enforced ¡at ¡runtime.) ¡*/ ¡ foo(X,Y), ¡foo(X,Z) ¡-­‑> ¡Y=Z. ¡ ¡ /* ¡Equivalent ¡sugared ¡declaration ¡*/ ¡ foo[X]=Y ¡-­‑> ¡int[64](X), ¡datetime(Y). ¡ ¡

SLIDE 23

Blox: ¡Facts ¡and ¡Updates ¡

23

/* ¡EDB ¡facts, ¡static ¡declaration ¡*/ ¡ a(“apple”). ¡ b(“apple”, ¡“banana”). ¡ ¡ /* ¡EDB ¡facts, ¡dynamic ¡insertion/retraction*/ ¡ +c(“hello, ¡world”). ¡

• ­‑d[1234] ¡= ¡true. ¡

SLIDE 24

Blox: ¡Procedural ¡and ¡Temporal ¡Aspects ¡

24

/* ¡Increment ¡g[X] ¡whenever ¡event(X) ¡occurs ¡*/ ¡ ^g[X]=Y+1 ¡<-­‑ ¡+event(X), ¡g@prev[X]=Y. ¡

• Inspired ¡by ¡work ¡on ¡Datalog ¡with ¡updates ¡[AbiteboulVianu91] ¡and ¡

states ¡[MotakisZaniolo95,Ludäscher98] ¡

time

g[1]=2 ¡ g[1]=3 ¡ +event(1) ¡

SLIDE 25 25

Blox: ¡EnHty ¡Types ¡

/* ¡Entities: ¡“pure” ¡keys, ¡opaque ¡and ¡unordered ¡*/ ¡ emp_id(Id) ¡-­‑> ¡. ¡ ¡ /* ¡Typical ¡usage: ¡associate ¡entities ¡with ¡ attributes ¡via ¡functional ¡predicates ¡*/ ¡ emp_name[Id]=Name ¡-­‑> ¡ ¡ ¡ ¡ ¡emp_id(Id), ¡string(Name). ¡

¡

emp_addr[Id]=Addr ¡-­‑> ¡ ¡ ¡ ¡ ¡emp_id(Id), ¡string(Addr). ¡ ¡ ¡

SLIDE 26

Blox: ¡Value ¡InvenHon ¡and ¡Data ¡Exchange ¡

26

/* ¡Data ¡in ¡external ¡format, ¡must ¡restructure ¡*/ ¡ emps(Name,Addr) ¡-­‑> ¡string(Name), ¡string(Addr). ¡ ¡ /* ¡Declare ¡a ¡constructor ¡for ¡emp_id’s ¡*/ ¡ cons_id[Name,Addr]=Id ¡-­‑> ¡ ¡ ¡string(Name), ¡string(Addr), ¡emp_id(Id). ¡ lang:constructor(`cons_id). ¡ ¡ /* ¡Exchange ¡emps ¡data ¡to ¡emp_name, ¡emp_addr ¡*/ ¡ cons_id[Name,Addr]=Id, ¡emp_name[Id]=Name, ¡ emp_addr[Id]=Addr ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡<-­‑ ¡emps(Name,Addr). ¡ ¡

SLIDE 27

Blox: ¡A ¡Simple ¡ApplicaHon ¡

• Data ¡Her ¡

– Sales ¡data ¡

• ApplicaHon ¡Her ¡

– Data ¡access ¡permissions ¡

• UI ¡Her ¡

– Compute ¡the ¡data ¡shown ¡on ¡the ¡UI ¡ – Handle ¡UI ¡events ¡

27

SLIDE 28

A ¡Simple ¡ApplicaHon: ¡Data ¡Tier ¡

28

/* ¡Partial ¡schema ¡(item, ¡day, ¡store, ¡employee ¡ are ¡entities ¡defined ¡elsewhere) ¡*/ ¡ sales[Prod, ¡Day, ¡Store] ¡= ¡Sales ¡-­‑> ¡ ¡ ¡ ¡ ¡item(Prod), ¡day(Day), ¡store(Store), ¡ ¡ ¡ ¡decimal[64](Sales). ¡ ¡ sold_in(Prod, ¡Store) ¡-­‑> ¡ ¡ ¡ ¡ ¡item(Prod), ¡store(Store). ¡ ¡ manager(Store, ¡Manager) ¡-­‑> ¡ ¡ ¡ ¡ ¡store(Store), ¡employee(Manager). ¡ ¡

SLIDE 29

A ¡Simple ¡ApplicaHon: ¡App ¡Tier ¡

29

/* ¡managers ¡can ¡modify ¡products ¡sold ¡in ¡their ¡ store ¡*/ ¡ modifiable_by(Prod, ¡Mgr) ¡<-­‑ ¡ ¡ ¡ ¡ ¡sold_in(Prod, ¡Store), ¡manager(Store, ¡Mgr). ¡ ¡

SLIDE 30

Simple ¡ApplicaHon: ¡UI ¡Layout ¡

30

sales_entry_form(Form) ¡-­‑> ¡form(Form). ¡ ¡ form_title[Form] ¡= ¡“Sales ¡Data ¡Entry” ¡ ¡ ¡ ¡<-­‑ ¡sales_entry_form(Form). ¡ ¡ component[Form] ¡= ¡Items, ¡ ¡ dropdown[Items] ¡= ¡Item, ¡ ¡ component[Item] ¡= ¡“item” ¡ ¡ ¡ ¡ ¡<-­‑ ¡sales_entry_form(Form). ¡ ¡ submit_button[Form] ¡= ¡Submit, ¡ ¡ label[Submit] ¡= ¡“submit” ¡ ¡ ¡ ¡ ¡<-­‑ ¡sales_entry_form(Form). ¡ ¡ ¡

SLIDE 31 31

SLIDE 32

UI ¡View ¡is ¡a ¡Database ¡View ¡

32

dropdown_values(Items, ¡Item) ¡<-­‑ ¡ ¡ ¡ ¡ ¡ ¡ ¡component[Form] ¡= ¡Items, ¡ ¡ ¡ ¡sales_entry_form_user(Form, ¡User), ¡ ¡ ¡ ¡ ¡ ¡ ¡modifiable_by(Item, ¡User). ¡ ¡ ¡

SLIDE 33

UI ¡Event ¡Handling ¡

33

^sales[Prod, ¡Date, ¡Store] ¡= ¡Val ¡<-­‑ ¡ ¡ ¡ ¡ ¡ ¡ ¡+button_clicked(Form, ¡Submit), ¡ ¡ ¡ ¡ ¡ ¡ ¡sales_entry_form_user(Form, ¡User), ¡ ¡ ¡ ¡ ¡ ¡ ¡dropdown_selected[Form] ¡= ¡Prod, ¡ ¡ ¡ ¡ ¡date_f_value[Form, ¡Date_f] ¡= ¡Date, ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡num_f_value[Form, ¡Val_f] ¡= ¡Val, ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡manager(Store, ¡User). ¡ ¡ ¡

SLIDE 34

Blox: ¡StraHficaHon ¡Revisited ¡

• StraHficaHon ¡turns ¡out ¡to ¡be ¡annoying ¡to ¡work ¡around ¡in ¡

pracHce ¡(esp. ¡wrt. ¡aggregaHon) ¡

– AggregaHons ¡on ¡lavce-­‑structured ¡OLAP ¡cubes, ¡prewy-­‑prinHng ¡ASTs, ¡ Hme-­‑series ¡simulaHons, ¡… ¡

• Our ¡approach: ¡allow ¡recursion ¡through ¡aggregaHon/negaHon ¡

via ¡staged ¡par-al ¡fixpoint ¡semanHcs ¡

– ConservaHve ¡extension ¡of ¡straHfied ¡semanHcs ¡ – Can ¡guarantee ¡(PTIME) ¡terminaHon ¡for ¡commonly ¡occurring ¡pawerns ¡

• Gives ¡the ¡expected ¡behavior ¡for ¡examples ¡above, ¡and ¡many ¡

classical ¡problems ¡too ¡

– company-­‑controls, ¡parts-­‑subparts, ¡shortest ¡paths, ¡… ¡

34

SLIDE 35

Blox: ¡Staged ¡ParHal ¡Fixpoint ¡SemanHcs ¡

35

p q r s

`

agg, ¬, etc ¡okay ¡

Dependency ¡graph ¡ Evalua.on ¡stages ¡ ( ¡0. ¡EDB ¡predicate ¡p ¡) ¡

• 1. ¡PFP ¡computaHon ¡of ¡q, ¡r ¡
• 2. ¡PFP ¡computaHon ¡of ¡s ¡

SLIDE 36

Other ¡Features ¡of ¡Blox ¡

• Higher-­‑order ¡predicates ¡

– Aggregate ¡funcHons ¡ – IntegraHon ¡with ¡solvers ¡for ¡opHmizaHon ¡ – Machine ¡learning ¡algorithms ¡

¡

• Generics ¡

– cf. ¡Shan ¡Shan ¡Huang’s ¡talk ¡on ¡MoReBlox ¡at ¡Datalog ¡2.0 ¡1.0 ¡

• Provenance ¡and ¡debugging ¡
• Modules ¡and ¡libraries ¡
• Predicate ¡lifeHmes ¡

36

SLIDE 37

• 1. Vision ¡
• 2. Language ¡
• 3. Run.me ¡

SLIDE 38

LogicBlox ¡RunHme ¡

• An ¡industrial-­‑strength ¡DBMS ¡supporHng ¡Blox ¡language, ¡

efficient ¡incremental ¡maintenance, ¡ACID ¡semanHcs, ¡failure ¡ recovery, ¡etc. ¡

• <= ¡v3.x: ¡convenHonal ¡DBMS ¡architecture, ¡lock-­‑based ¡

concurrency, ¡semi-­‑naïve ¡evaluaHon, ¡DRed ¡for ¡maintenance ¡

– “She’s ¡old, ¡but ¡she’ll ¡hold!” ¡

• v4.0: ¡complete ¡reimplementaHon ¡from ¡scratch, ¡rethinking ¡

many ¡architectural ¡fundamentals ¡

– Clean ¡design, ¡sophisHcated ¡data ¡structures ¡and ¡algorithms, ¡self-­‑tuning, ¡ very ¡high ¡performance ¡

• Ideas+results ¡in ¡remainder ¡of ¡slides ¡are ¡due ¡to ¡Todd ¡

Veldhuizen ¡(runHme ¡architect) ¡

38

SLIDE 39

Concurrent ¡TransacHons ¡in ¡v4.0 ¡

• TradiHonal ¡DBMS ¡concurrency ¡control ¡is ¡based ¡on ¡locks, ¡and ¡

uses ¡(compromised) ¡isolaHon ¡levels ¡like ¡REPEATABLE ¡READ ¡to ¡ provide ¡reasonable ¡throughput ¡

• Our ¡posiHon: ¡

– Locks ¡are ¡a ¡woefully ¡inadequate, ¡stone-­‑age ¡technology ¡ – IsolaHon ¡levels ¡like ¡REPEATABLE ¡READ ¡are ¡semanHcally ¡ unsound, ¡dangerous, ¡and ¡ulHmately ¡inexcusable ¡

• Our ¡approach: ¡

– Use ¡versioned ¡data ¡structures ¡(≠ ¡MVCC!) ¡for ¡concurrency ¡ – Provide ¡fully ¡ACID, ¡fully ¡serializable ¡transacHons ¡with ¡high ¡ throughput ¡

39

SLIDE 40

Storage ¡and ¡Indexing ¡in ¡v4.0 ¡

• Current ¡DBMS ¡storage ¡architectures ¡are ¡tailored ¡to ¡specific ¡

workloads: ¡ – OLTP ¡=> ¡row ¡store ¡ ¡ – OLAP ¡=> ¡column ¡store ¡ – mixed ¡=> ¡? ¡

• Our ¡approach: ¡key-­‑value ¡store ¡

– A ¡predicate ¡p[X,Y]=Z ¡stored ¡in ¡paged, ¡cache-­‑aware ¡data ¡ structure ¡based ¡on ¡(cascading ¡collecHons ¡of) ¡trees ¡ – Light ¡compression ¡for ¡cachelines ¡and ¡in-­‑memory ¡pages, ¡ heavier ¡compression ¡for ¡on-­‑disk ¡pages ¡

40

SLIDE 41

Storage ¡and ¡Indexing ¡

• RelaHonal ¡and ¡funcHonal ¡predicates ¡treated ¡uniformly: ¡

relaHonal ¡predicates ¡are ¡modeled ¡as ¡nullary ¡funcHons ¡

• Indices ¡are ¡views ¡(automaHcally ¡generated ¡and ¡managed ¡by ¡

the ¡opHmizer) ¡which ¡project ¡and ¡reorder ¡awributes ¡ ¡f_31(Z,X) ¡<-­‑ ¡f[X,Y] ¡= ¡Z. ¡

41

SLIDE 42

TradiHonal ¡B-­‑Trees ¡and ¡Cache ¡Hierarchy ¡

• Each ¡page ¡has ¡a ¡vector ¡of ¡records ¡
• Binary ¡search ¡to ¡locate ¡records ¡

Problem: ¡Binary ¡search ¡performs ¡dreadfully ¡on ¡modern ¡

• computers. ¡

42

SLIDE 43

Binary ¡Search ¡

43

SLIDE 44

Cacheline ¡Trees ¡in ¡v4.0 ¡

44

SLIDE 45

Cacheline ¡Tree ¡Performance ¡

45

SLIDE 46

Trie ¡Model ¡in ¡v4.0 ¡

• To ¡best ¡exploit ¡the ¡performance ¡possibiliHes ¡of ¡key-­‑value ¡

stores, ¡we’ve ¡rethought ¡the ¡basics ¡of ¡how ¡queries ¡should ¡be ¡

• pHmized ¡and ¡evaluated ¡
• Conceptually, ¡relaHons ¡& ¡funcHons ¡are ¡viewed ¡as ¡tries: ¡

¡

• Each ¡tuple ¡is ¡a ¡path ¡from ¡the ¡tree ¡root ¡to ¡a ¡leaf ¡

46

SLIDE 47

Leapfrog ¡Joins ¡

47

• The ¡workhorse ¡of ¡our ¡query ¡evaluator ¡is ¡a ¡leapfrog ¡tree ¡join ¡

algorithm, ¡based ¡on ¡binding ¡tries ¡

• Handles ¡conjuncHon, ¡disjuncHon, ¡and ¡complementaHon, ¡and ¡

joins ¡such ¡as ¡A(x,y,z),B(x,z),C(y). ¡

• For ¡A(x,y,z),B(x,z),C(y) ¡we ¡do ¡a ¡simultaneous ¡3-­‑way ¡

join, ¡rather ¡than ¡joining ¡pairwise ¡and ¡generaHng ¡intermediate ¡

• results. ¡
• Theorem: ¡leapfrog ¡join ¡algorithm ¡is ¡worst-­‑case ¡opHmal ¡in ¡the ¡

sense ¡of ¡[Ngo+ ¡PODS ¡12] ¡

SLIDE 48

Maintenance ¡in ¡v4.0 ¡

• Maintenance ¡= ¡efficiently ¡revise ¡query ¡result, ¡given ¡changes ¡

to ¡inputs ¡

• MoHvaHon: ¡

1. Large ¡volume ¡of ¡installed ¡logic ¡that ¡needs ¡to ¡be ¡maintained ¡for ¡ transacHons ¡(e.g. ¡live ¡analyHcs)-­‑-­‑-­‑up ¡to ¡100,000 ¡rules ¡and ¡predicates ¡ in ¡current ¡LB ¡apps ¡

• Fully ¡re-­‑evaluaHng ¡queries ¡is ¡prohibiHvely ¡expensive, ¡even ¡

for ¡in-­‑memory ¡databases ¡

– E.g. ¡64Gb ¡of ¡data ¡è ¡typical ¡main ¡memory ¡bandwidth ¡3Gb/s ¡è ¡21 ¡ seconds ¡just ¡to ¡stream ¡the ¡data ¡through ¡CPUs ¡

48

SLIDE 49

Maintenance ¡(Incremental ¡EvaluaHon) ¡

• General ¡incremental ¡evaluaHon ¡problem: ¡when ¡inputs ¡

change, ¡how ¡to ¡efficiently ¡update ¡the ¡outputs? ¡

• ConvenHonal ¡approaches ¡in ¡Datalog ¡literature, ¡like ¡semi-­‑

naive ¡evaluaHon ¡and ¡DRed, ¡are ¡based ¡on ¡logical ¡ rewriHngs ¡and ¡are ¡oblivious ¡to ¡the ¡underlying ¡query ¡ evaluaHon ¡mechanisms ¡

• Our ¡leapfrog ¡joins ¡lend ¡themselves ¡to ¡a ¡very ¡efficient ¡

maintenance ¡method, ¡which ¡draws ¡on ¡standard ¡PL ¡ techniques ¡and ¡extends ¡them ¡with ¡some ¡database-­‑ specific ¡innovaHons ¡

49

SLIDE 50

Background: ¡Trace ¡of ¡a ¡ComputaHon ¡

• When ¡an ¡input ¡changes, ¡we ¡don’t ¡want ¡to ¡recompute ¡from ¡

scratch; ¡instead ¡just ¡revisit ¡those ¡steps ¡that ¡need ¡maintaining: ¡

• The ¡minimum ¡number ¡of ¡changes ¡we ¡need ¡to ¡make ¡to ¡turn ¡
• ne ¡trace ¡into ¡another ¡is ¡the ¡trace ¡edit ¡distance ¡

50

(1+2)*(4+5) ¡

• 1. Add ¡1+2 ¡= ¡3 ¡
• 2. Add ¡4+5 ¡= ¡9 ¡
• 3. MulHply ¡3*9 ¡= ¡27 ¡

¡ (1+ )*(4+5) ¡

• 1. Add ¡1+ ¡= ¡ ¡
• 2. Add ¡4+5 ¡= ¡9 ¡
• 3. MulHply ¡ *9 ¡= ¡

¡ ¡

SLIDE 51

Maintenance ¡AspiraHon ¡

• Our ¡goal: ¡maintenance ¡cost ¡propor-onal ¡to ¡trace ¡edit ¡distance ¡
• Maintenance ¡cost: ¡number ¡of ¡operaHons ¡performed ¡to ¡

maintain ¡the ¡query ¡output ¡in ¡response ¡to ¡changes ¡in ¡input ¡ predicates ¡

• Trace: ¡low-­‑level, ¡step-­‑by-­‑step ¡descripHon ¡of ¡query ¡evaluaHon ¡
• Trace ¡edit ¡distance: ¡conceptually, ¡do ¡full ¡evaluaHon ¡before ¡

and ¡aIer ¡changes, ¡and ¡measure ¡the ¡minimal ¡number ¡of ¡edits ¡ required ¡to ¡transform ¡the ¡“before” ¡trace ¡into ¡the ¡“aIer” ¡trace ¡

• proporHonal: ¡modulo ¡log ¡factors ¡

51

SLIDE 52

Maintaining ¡AggregaHons ¡in ¡v4.0 ¡

• We ¡use ¡special ¡data ¡structures ¡(scan ¡trees) ¡to ¡efficiently ¡

maintain ¡aggregaHons ¡such ¡as: ¡

¡

¡TopSkuSales[dept]=topsales ¡<-­‑ ¡

¡ ¡ ¡ ¡agg<<topsales=max(sales)>> ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡ ¡SalesBySku[sku]=sales, ¡ ¡ ¡ ¡ ¡SkuDept[sku]=dept. ¡

• If ¡k ¡records ¡change, ¡we ¡can ¡maintain ¡TopSkuSales ¡in ¡Hme ¡O(k ¡

log ¡N), ¡where ¡N ¡is ¡the ¡total ¡number ¡of ¡records ¡

• Cost ¡is ¡proporHonal ¡to ¡number ¡of ¡changes, ¡not ¡number ¡of ¡

records ¡touched ¡by ¡the ¡query ¡

52

SLIDE 53

MulHthreaded ¡ExecuHon ¡in ¡v4.0 ¡

53

SLIDE 54

MulHthreaded ¡ExecuHon: ¡TPC-­‑H ¡Q1 ¡

54

SLIDE 55

MulHthreaded ¡ExecuHon: ¡TPC-­‑H ¡

55

SLIDE 56

MulHthreaded ¡ExecuHon: ¡TPC-­‑H ¡Q6 ¡

56

• (Already ¡parallelized ¡in ¡

more ¡recent ¡builds) ¡

SLIDE 57

Other ¡Features ¡of ¡Interest ¡in ¡v4.0 ¡RunHme ¡

• Novel ¡compression ¡schemes ¡
• InnovaHve ¡sampling-­‑based ¡opHmizer ¡
• Efficient, ¡purely-­‑funcHonal ¡data ¡structures ¡
• Lock-­‑free ¡concurrency ¡control ¡
• Cache-­‑sensiHve ¡data ¡structures ¡
• Cluster ¡parallelism ¡
• … ¡

57

SLIDE 58

Conclusion ¡

• We’re ¡using ¡Datalog ¡as ¡the ¡foundaHon ¡of ¡our ¡approach ¡to ¡

dramaHcally ¡simplify ¡enterprise ¡applicaHon ¡development ¡

• PracHcal ¡necessiHes ¡moHvate ¡many ¡extensions ¡to ¡the ¡core ¡

language ¡(types, ¡constructors, ¡updates, ¡aggregaHon, ¡Hme, ¡…) ¡

– Database ¡theory ¡literature ¡has ¡been ¡a ¡frui€ul ¡source ¡of ¡inspiraHon ¡

• Building ¡an ¡industrial-­‑strength ¡system ¡from ¡the ¡ground ¡up ¡

(twice!) ¡has ¡allowed ¡us ¡to ¡revisit ¡basic ¡architectural ¡ fundamentals, ¡and ¡find ¡creaHve ¡new ¡approaches ¡that ¡ advance ¡the ¡state-­‑of-­‑the-­‑art ¡

58

SLIDE 59

Thanks, ¡and ¡come ¡visit ¡us ¡in ¡Atlanta! ¡

• We ¡love ¡collaboraHng ¡with ¡academic ¡researchers, ¡and ¡we ¡do ¡

it ¡oIen ¡

¡

• Also, ¡we’re ¡hiring! ¡ ¡(Interns ¡and ¡full ¡Hme) ¡

– Ideal ¡profile: ¡PhD ¡with ¡strong ¡engineering ¡skills ¡who ¡is ¡also ¡ comfortable ¡with ¡formal ¡methods ¡ – ExperHse ¡in ¡database ¡systems, ¡database ¡theory, ¡distributed ¡systems, ¡ programming ¡languages, ¡logic ¡programming, ¡machine ¡learning, ¡or ¡

• peraHons ¡research ¡preferred ¡

59