> A NEW GENERAL PURPOSE DATABASE DESIGNED FOR BIG DATA
AND THE CLOUD THAT PERFORMS SIMULTANEOUS TRANSACTIONS
AND ANALYTICS … IN REAL-TIME, ON THE SAME DATA SET
Well they certainly have all the right buzzwords present in their pitch. Other than that there's very little to go on right now as to how much merit their product deserves.
1 CEO
1 CTO
3 Founders
1 Chairman
1 VP Product Management
1 VP Sales
1 Controller
1 Director of Engineering
1 Architect
1 Consultant
2 Engineers
Yeah... sounds like exactly the company i would never buy from. A company which basically consistes of 80% "upper management" positions and barely any "real workers"..
Especially when the website is only about marketing claims and very unspecific details.
I can't even find downloads or documenation..
Virtually outsourced engineering as well -- a separate "corporate office" and "engineering office" in two different states, with the business people and founders working at the corporate one.
Those kind of companies nearly always fail. Engineering feels like the engine room on the Titanic, C levels escaping with lucre while the boilers are stoked.
Those bios are a bit strange. They all manage to fill multiple paragraphs without actually saying anything relevant about themselves. Instead it's just strings of empty phrases like "I make magic happen" or "my DNA pushes me to always seek out the vanguard of technology". (Your DNA, really? Did one of your ancestors invent fire?)
To read the real bios, you need to click through to the people's LinkedIn profiles. This reveals that the founders come from companies like Oracle. I don't know if that explains anything.
VirtualIron was a huge disaster of a company - they pivoted multiple times without ever finding market fit, then pissed off potential acquirers with their attitude, after which they laid everyone off and sold the remains to Oracle for a pittance ( I remember hearing it was ~$10m).
You need all of the senior folks to manage the two engineers and tell them what to do and subtly deflect criticism towards them when things go wrong. Is it not the case that the business folks are entitled to and have the right to the fruits of the engineers' hard work?
To be fair, all of their team except one come from technical backgrounds. There are three other engineers (Michael Jeffords - CTO's relative?, Vincent King and Richard Soczewinski) listed as employees on LinkedIn. That puts the split at 10:6, which looks healthy. I'd be more worried about the lack of information and the fairy tales on the product's website.
It amazes me that HN users would spend time commenting here before taking a few seconds to navigate a website. Here is an overview of technical information: http://deep.is/knowledge/deepdb-white-paper/
These are the interesting things that sticks out to me:
The understanding that storage system throughput is maximized by using sequential access patterns led to the creation of streaming, append-only transactional and indexing algorithms. Our approach is unique in that all database files (i.e. transactional state, indexes, and metadata) are streamed, append-only files.
...
The CASI Tree breaks from a traditional b-tree on-disk approach, eliminating update in-place operations on fixed size pages. Instead, the CASI Tree is an append-only Purely Functional Tree data structure.
...
A complete database audit trail is maintained when running in archival mode, making all previous database states available. These states may be queried in read-only mode, efficiently supporting read-only analytics of point-in-time transactional database states
This makes me wonder how much research this team really did. I'm not ready to claim they haven't done it, but it raises the question. I would like to see the actual data structure published somewhere.
Perhaps I am missing something, but color me skeptical... immutable on-disk structures essentially means that you have to perform run-time compactions on every query... unless your in-memory representation is the cache, in which case you have to worry about durability.
One of the things I was left puzzled with was how could one efficiently leverage a transaction log and data organization for querying all in the same file without memory mapping and have this perform well. Maybe the implementation they are using is part of DeepDb special sauce?
Also it seems the company is very young and so many of the things other posters are expecting such as a large engineering team, feature matrixes and downloadable demos arent in place yet and will be soon
Experience has taught me to be naturally skeptical when a startup says they designed a database from the ground up. It seems like they put every buzzword of machine learning and database design into their website, and the staff seems to be primarily management people and only a handful of engineering staff.
But who knows, maybe in 5 years we'll be doing our business analytics with DeepDB, but most likely we'll be doing business analytics with a tool that doesn't seem this sketchy.
Not to be too critical since I like database startups as much as the next guy, but there is almost nothing original in their approach to database engines. Most of their assertions about existing databases only apply to relatively weak open source databases; on the high-end databases don't work the way they are assuming at all, which makes me wonder how much they actually know about database engine internals generally. Architecturally, DeepDB goes into the same bucket as PostgreSQL in terms of capabilities and scalability, albeit a different design.
As a more technical nitpick, "high availability" does not mean fast restarts. It means never goes down. The design as described is not a high availability architecture.
Bonus observation: if you assert your database engines uses extensive fine-grained locking, don't show a chart with 24 cores at ~100% utilization and call it "efficient". This is what you would expect to see for a poorly designed and very inefficient implementation for this type of architecture. You can be burning all of your CPU and getting very little throughput. A credible presentation would have demonstrated that system throughput scales linearly with the number of cores (unlikely given the description of their internals).
I don't have anything to add other than I would like run a demo before drawing any technical opinions.
However, given the management structure and general sales tone of the website (and its joke of a technical FAQ), it looks like DeepDB is totally gunning for enterprise sales. Is HN even the right venue for this?
32 comments
[ 2.7 ms ] story [ 25.7 ms ] threadWell they certainly have all the right buzzwords present in their pitch. Other than that there's very little to go on right now as to how much merit their product deserves.
No, i'll stay away.
To read the real bios, you need to click through to the people's LinkedIn profiles. This reveals that the founders come from companies like Oracle. I don't know if that explains anything.
I'm puzzled.
http://bits.blogs.nytimes.com/2009/05/22/with-virtual-iron-o...
These are the interesting things that sticks out to me:
The understanding that storage system throughput is maximized by using sequential access patterns led to the creation of streaming, append-only transactional and indexing algorithms. Our approach is unique in that all database files (i.e. transactional state, indexes, and metadata) are streamed, append-only files.
...
The CASI Tree breaks from a traditional b-tree on-disk approach, eliminating update in-place operations on fixed size pages. Instead, the CASI Tree is an append-only Purely Functional Tree data structure.
...
A complete database audit trail is maintained when running in archival mode, making all previous database states available. These states may be queried in read-only mode, efficiently supporting read-only analytics of point-in-time transactional database states
This makes me wonder how much research this team really did. I'm not ready to claim they haven't done it, but it raises the question. I would like to see the actual data structure published somewhere.
It seems to be optimising to remove the ETL step of transactional - analytical data migration, but you still need the analytical speed.
But who knows, maybe in 5 years we'll be doing our business analytics with DeepDB, but most likely we'll be doing business analytics with a tool that doesn't seem this sketchy.
Axiom 1: Information is a sequence of Information (self-similar) that is segmented by consistent (well-formed) order.
Axiom 2: Segmented Information is addressable by the First where a sequence of Firsts is a Segment of Summarization.
Axiom 3: Information of a Segment is equal distance to the sequence of Information between non-associated Summarizations.
Axiom 4: Sequenced Information is in direction relation to former and later Information of which Patterns can be Matched.
I don't know what any of that means. Worse, it sounds to me like "cargo-cult" computer science.
As a more technical nitpick, "high availability" does not mean fast restarts. It means never goes down. The design as described is not a high availability architecture.
Bonus observation: if you assert your database engines uses extensive fine-grained locking, don't show a chart with 24 cores at ~100% utilization and call it "efficient". This is what you would expect to see for a poorly designed and very inefficient implementation for this type of architecture. You can be burning all of your CPU and getting very little throughput. A credible presentation would have demonstrated that system throughput scales linearly with the number of cores (unlikely given the description of their internals).
However, given the management structure and general sales tone of the website (and its joke of a technical FAQ), it looks like DeepDB is totally gunning for enterprise sales. Is HN even the right venue for this?