Webinar: NoSQL Technology and Real-time, Accurate Predictive Analytics
Q: With so much data — “Data Visualization” becomes a challenge. Can you address that please?
A: Absolutely correct. Part of the trick is to use powerful analytical queries to refine what has to be visualized. The National Visualization Consortium has done a lot of work in this area. Objectivity works with specialized vendors, such as Cambridge Intelligence and Tom Sawyer Software, to customize specialized visualizations to an application domain.
Q: Speaking of commodity clusters, I can’t find any on AMI on Amazon. plans for releasing something there?
A: Both Objectivity/DB and InfiniteGraph, being distributed databases and systems, can be deployed in EC2.
Q: Is it possible to plug Objectivity DB into a Oracle DB through Oracle Heterogeneous Service ( with ODBC connection ) ?
A: You can use Objectivity/SQL++ to access an Objectivity/DB federation via ODBC. However, that is the least performant API because of the SQL overheads and paradigm mismatch.
Q: Do you plan to support RDF&SPARQL capability by InfiniteGraph.I think they will be the important features to control Open Data/Linked Data.What do you think about it? Are they out of scope?
A: RDF can be imported (see the Samples area) into InfiniteGraph and then accessed via the Java API. SPARQL is designed for RDF and isn’t very good at handling hypergraphs or property graphs. We have been encouraging the community to standardize a graph query language, but we need the support of other graph database vendors to agree on a standard in order to be successful.
Q: How does this relate to what we call Master Data Management today?
A: Both Objectivity/DB and InfiniteGraph can be used to construct MDM systems. Some of the earliest products in taht area were built using Objectivity/DB and we have customers using Objectivity/DB as a repository for miscellaneous material and InfiniteGraph as the query API.
Q: Graph databases deal with instances. So they share this feature with object databases, which actually stored the relationships of an object with other objects within that object. Is that right ? 2. However, isn’t it in reverse more difficult to aggregate/group similar items ?
A: Object databases store objects with a unique instance identifier (an OID) and use the OID in related structures that can represent associated objects, collections etc. Grouping (clustering) is a function of a particualr ODBMS implementation. Objectivity/DB and InfiniteGraph have powerful clustering capabilities that can be expressed on individual new() statements, as policies or as declarative placement strategies.
Q: Does Objectivity normally use 3rd parties to build the end solution or the use tools to help automate the solution building process?
A: Yes. We work with many of the big integrators in the defense and other spaces and are always looking for solution builders prepared to be trained to recognize opportunities and deliver solutions suited to our technology
Q: The speedups that we have observed are directly proportional to the difference in latency. For example, accessing an object in memory takes about 80 to 100 ns, whereas accessing it on disk takes about 4 milliseconds. However, if the algorithm doesn’t fit in memory you’ll be out of luck with solutions that solely rely on RAM.
Q: Do you integrate with advanced visual analytics tools initially targeting relational DBs?
A: We don’t currently offer direct interfaces, but we’re working on a solution. You can use ODBC with Objectivity/DB (via Objectivity/SQL++)
Q: What are some use cases where real world benifits have achieved: Improved healthcare outcomes, reduced cost of healthcare etc.
Q: Will NoSQL databases replace relational databases 5-10 years down the line?
A: In general, No. Relational techinology is here to stay because it’s well suited to a wide variety of problems and is reasonably adaptable. The NoSQL solutions are primarily designed to do thingsthat current RDBMS aren’t good at. You may see column family stores being the first to be made redundant by extended RDBMS, followed by K-V stores and document stores. Current RDBMSs are inherently bad at tackling graph problems efficiently.