Opasnet Base: Difference between revisions
m (→See also) |
m (→Mongo) |
||
Line 161: | Line 161: | ||
|} | |} | ||
== | ==MongoDB== | ||
=== Tables to store all locations and results === | |||
'''db.<obj.ident>.dat''' | '''db.<obj.ident>.dat''' | ||
id(dat.id, indexed), <ind.id>, <ind.id>, ..., <ind.id>, res | |||
=== Tables to store real location values for entity type indices ? === | |||
'''db.<obj.ident>.locs''' | |||
ind_id(indexed), key, value | |||
==See also== | ==See also== |
Revision as of 10:39, 9 February 2012
Moderator:Jouni (see all) |
|
Upload data
|
This page is about the Opasnet Base 2 -database.
Question
How to improve the existing Opasnet Base? Following issues of Opasnet Base 1 must be resolved:
- Opasnet Base 1 structure makes filtering by location very slow on big data
- Opasnet Base 1 structure is perhaps unnecessarily complex = queries are hard to adapt and read
- MySQL is not ideal for storing huge amounts of data, or at least this is how we assume?
- MySQL tables have fixed column types = difficult to store data objects with varying types of indices into one data table
- Multiple languages (localization) not supported
Answer
MySQL is good on relations but weak on dynamic big data. Let's keep the basic "scaffold" in MySQL and store the big data (locations and results) into noSQL-base. After few days of research the best candidate for noSQL-base seems to be MongoDB. Combining relational MySQL and non-relational MongoDB will be the foundation for the new Opasnet Base 2.
Table structure in the database
All tables
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
MongoDB
Tables to store all locations and results
db.<obj.ident>.dat
id(dat.id, indexed), <ind.id>, <ind.id>, ..., <ind.id>, res
Tables to store real location values for entity type indices ?
db.<obj.ident>.locs
ind_id(indexed), key, value