-
Notifications
You must be signed in to change notification settings - Fork 10
Data Model
WAL: Write a Log first when a write comitted.
records in the following simple formart:
{name=jack, age=30, payment=500, date=20150728, description=["it's ok, i know it."]}
{name=michael, age=25, payment=800, date=20150728, description=["LunarBase is a powerful database system."]}
{name=frank, age=25, payment=1200, date=20150729, description=["I'm a honest man."]}
{name=jackson, age=45, degree=master, address=somewhere, payment=2000, description=["great, it's free!"]}
......
name, age, payment, date and all these alike are columns, programmers need no definition of the schema before inserting real data. The columns are searchable after invoke
addSearchable(String column_name)
or
addFulltextSearchable(String column_name)
explicitly. Lunarbase build column storage for every column that is added.
Records has a size limitation up to 32KB. Exceeding part of a record will be discarded.
Log system is first of all we implemented, every command user commits is recorded before execute real database operation:
**succeed**@ insert: {name=jack, age=30, payment=500, date=20150728, description=["it's ok, i know it."]};
**succeed**@ insert: {name=michael, age=25, payment=800, date=20150728, description=["LunarBase is a powerful database system."]};
**succeed**@ insert: {name=jackson, age=45, degree=master, address=somewhere, payment=2000, description=["great, it's free!]"};
Schema Free, all columns are added on demand. As what the example illustrates, name, age, payment, date appears when new records inserted. In future, the coming data may includes new columns like address, school, LunarBase recognizes these, and stores them automatically:
property@ name, age, payment, date, degree, favorite......
Remark:
Columns of a Data Application is the very first thing need to be clear when start to design and program in old days. But now, the data types variants much more frequently than before, no one has the ability to know the future category a bunch of data belongs to.
This is what the industry calls ** Scalability** and Flexibility, an advantage of NoSQL database.
1 Home
1.1 summary
1.2 System Preparation
1.3 When LunarBase is your best choice
1.4 Benchmark
1.5 Power consumption
2 Data Model And Process
2.1 Why internal big cache
2.2 Memory Management: LunarMMU
2.3 Garbage Collection
2.4 Transaction Log
2.5 JOIN via materialized view
3 Real Time Computation: LunarMax
3.1 In-Memory File System: Memory Estimation
3.2 Configuration
3.3 Use SSD as a cheaper memory
3.4 Data Safety
3.5 HE Server VS. Cluster
3.6 High Availability
4 Create a database
4.1 Three modes
4.2 creation.conf settings
4.3 Table space
4.4 Multiple Instance
4.5 Database Status
4.6 Remove and Restore a table
5 Insertion
5.1 Insert as normal record
5.2 Insert to search engine
6 Query
6.1 Point Query
6.2 Result Handler: register your own event handler
6.3 Interpreter Pattern: complex query conditions
6.4 Range Query
6.5 Full-text Search
6.6 Algebraic Logical Query
8 Deletion
9 Materialized view
9.1 Eventual consistency
9.2 Update
9.3 MVCC in LunarBase
9.4 Easy JOIN via denormalization
9.5 CRUD in view
10 Distributed integration with
10.1 Kafka
10.2 Storm
10.3 Spark
11 Storage: Lunar Virtual File System
13 Roadmap of LunarBase future
15 FAQ