2. Topics  In-memory Spatial Database based on key-value pair  Building Information Model based on relationship inference

3. In-memory Spatial Database based on key-value pair  Background  Architectural Overview  Features

4. Background This research is supported to solve kernel issues during the State Grid information construction. The achievements have been applied to the power information systems.

5. Deploy view State Grid Shanghai Grid … User1User2… Hubei Province Grid Beijing Grid User1User2… User1User2… User1User2…

6. NetworkStorage Software… Physical ResourceGraphics … Vector Database ManageAnalysis … Spatial Power Grid Services ERPMarking GIS… Systems PlanningSchedule Sale… Businesses Security Data Network System … Application Integrate Product Monitor Emergency … Technical Architecture

7. Background Store Data Organize Data Access Data Others Large scale data Key-value Transaction Locks Lazy write to DBMS High concurrency High throughout Batch to submit data long period, offline data edit Increment data query Can’t be accessed directly by user hybrid index based on spatial and topology Change notify Reuse existing power database, such as Oracle Spatial, SDE, DB2 Spatial Extender Data synchronize … Key problems Partition based on spatial and topology logical data model Version History Database

8. Background Why not traditional spatial database?  Why not DBMS, such as Oracle?  Why not SDE or ArcServer?  Why not object-oriented, such as Oracle spatial?  Why not traditional spatial index, such as Quad-tree, R*- tree? Bad I/O throughout Bad performance when high concurrency and batch edit Can’t provide necessary features Bad performance There are some bugs in Linux Can’t provide necessary features More slow than raw data type, such as BLOB Spatial index has bugs and has to be rebuilt at fixed period Spatial index performance is bad Precise filter is even slow, such as sdo_relate Spatial function is not necessary No. We need a hybrid index, including spatial, topology and attributes information

9. Background Why in-memory spatial database on key-pair  Why store data in memory? How is the data persistence?  Why use key-pair? What is your spatial model?  Do you use spatial index?  Do you support condition query like SQL? in-memory database is much fast than disk database The changed data will be written into DBMS Simple means high performance! In-memory database doesn’t need complex search We use the hybrid index, including spatial, topology and attribute information We support simple compare function,such as greater, equal, less…

10. Architectural-Logical View

11. Architectural-Framework

12. Features-Data Model Indeed, e very record is a memory block!  Typical data struct  Index for attributes B-tree index, Hash index  Spatial index Spatial index is a hybrid index: B-tree + grid index + topology based index protocol head description field value 1 field value 2 … field value n

13. Features-Cluster In my research, cluster is a group of virtual, loosely coupled in- memory database that work together closely.  In a cluster, all in-memory databases have the same data.  For different group, maybe they have intersected data.  How to partition the power data for cluster is based on the spatial, topology and attribute information  When some data are updated in one in-memory database, other in-memory database which has these data will be synchronized almost real-time.

14. Features-Change notify When data is update, clients will receive the notify. TThe notification granularity is based on object, not record, which help to TThe notify is based on subscribe & notify model. UUser can only download changed records.

15. Features-Version & History DB Provide version mechanism and history database based on time axis.  Sometimes, work maybe needs several days, even a month to finish. These data will be managed as a version and other client can’t see them before finishing the work.  At any time, in-memory can create database snapshot for archive or future comparative analysis.

16. BIM based on relationship inference  Background  Roadmap

17. Background  In common, the life cycle of a building includes 3 phases:  IFC is a vendor-neutral BIM data repository for the semantic information of building objects, including geometry, associated properties, and relationships, to facilities.

19. Background Impression  IFC is a complex, relatively complete and huge specification.  From the OO point of view, IFC is a well designed and loose coupled class set.

20. Background Problems and Limitations for IFC  For OO design, message or event driven is an import design pattern, but it seems there is no definition about it.  IFC doesn’t define something about analysis, which is important for management phase during the life cycle of a building.  The ability of relationship description is much weak and can not describe the implicit relationship automatically, which is import for analysis and modeling. GIST belong to OTB Liu belong to GIST Liu belong to OTB

21. Roadmap Goals  Provide the ability of relationship inference.  Improve the degree of automation during the process of building information modeling.  Provide a mechanism for building information analysis

22. Roadmap-relationship inference Classification based on the number of relation unary Binary triple Classification based on type subsumption(subClass- of, superClass-of, …) mereology(is-part-of,) topology(next-to, touch- with, …) …. transitive symmetric inverse equality hasValue exists at occur at maximum minimum

23. Roadmap-analysis based on event driven Initial thoughts  Information transmission is modeled a virtual pipeline.  Every object will get information from pipeline and analyze them. The result is also pushed into the pipeline.  The purpose: 1) object is self-contain; 2) object is independent of other object; 3) combine different analysis

24. Thank you