arosenbaum

Asking permission for eye tracking in a Magic Leap app is like asking permission to read screen touches in a mobile app...It's not an enhancement to the experience, it's fundamental to the platform - they need to do eye tracking to render AFAIK...

AWS has consistently stated Aurora storage spans 3 AZs. I believe some 2 AZ regions have a third AZ for internal AWS use only (not a 3rd DC in small regions but otherwise a separate AZ). I would imagine they might run the 5th + 6th copies in storage cells there...seems more likely than the other options...

Please post link where they talk about transactions - I can't find it in the docs anywhere. Availability SLA is clearly not 5 9's - https://azure.microsoft.com/en-us/support/legal/sla/cosmos-d...

The "CPU usage across our Elasticsearch cluster" chart shows a very large spread of utilization at almost all times. This is read-only since you are re-writing offline, right? What do you think is driving this variation?

Disclosure: I am VP, Product Strategy at MarkLogic...

The stats were driven by the "Vehicle Hacking Vulnerability Survey". " How do you feel about autonomous or self-driving vehicles?" was asked alongside questions like "How big of a problem do you feel vehicle hacking will be in the future?"

If the questions were "How safe a driver is your 75yo mother?" or "Do you think autonomous cars will increase or decrease deaths caused by drunk driving?" the survey might have shown different results.

http://developer.marklogic.com is the place to go.

The closest we have to a "comparison" is http://www.marklogic.com/what-is-marklogic/features/ those pages do actually end drilling down to documentation.

You are a manager but you didn't state anything in your story about the people you hired and developed, the projects you led or rescued, or how you contributed to your peers, managers and companies success. Do that.

>I would not recommend NoSQL for something like a banking Many of the leading banks in the world have replaced Oracle with NoSQL (generally MarkLogic) for key systems. Abadi explained quite clearly why NoSQL is not incompatible with transactions and updates.

How can one possibly be eventually consistent for reads and ACID for updates? Unless you are saying the datasets available for fast queries cannot be updated consistently...Or are you just saying, you can read from replicas but maintain a single master...

They absolutely apply to MarkLogic. We absolutely prioritize FI over T. Coordinating transactions, along with journaling, security and many other features costs in terms of throughput. Now, that cost is relative - our ingest rates are still very quick and we linearly scale. That said, copying JSON or XML into a distributed file system is way quicker.

I'm not sure the buckets provide much guidance in real life. One can configure a system, for an insert only batch load, to prioritize T without giving up FI for the data and transactions that aren't part of that load. If an FI system can load faster than an IT system, this distinction ends up not actually mattering. Plenty of folks who need FI are using products that don't provide it because of culture + budget.

Misleading title: Abadi specifically called out particular NoSQL DB's, he wasn't generalizing to all NoSQL DB's. MarkLogic (http://www.marklogic.com) is an Enterprise Database used by many large organizations as a system of record for information traditionally stored in RDBMS or Mainframe.

Joe Hellerstein gave a wonderful keynote at ACM SoCC last year that is a great read for all who are interested in this subject: http://db.cs.berkeley.edu/jmh/talks/SoCC14-keynote.pdf

MarkLogic has had transactions since version 1.0. The same mechanisms that enable multi-statement transactions are also critical for overall reliability. A recent Gartner study ranked MarkLogic as #3 for reliability (not NoSQL databases, all databases).

Many on HN may have not heard of MarkLogic as we are not open source. We are, however, the largest NoSQL ISV by employee count (and probably other measures also.)

I am VP, Product Strategy for MarkLogic (ExIngres, ExCohera)

I built mine quite a few years ago: https://goo.gl/photos/CrX2pSaAmgnLNM398 (The monitor arrangement is much better now :)

Precor 956i with the entire upper structure removed - control panel is not visible but on the left. I bought it from a gym going out of business.

Lift is a Conset 501-11 1B116. I don't remember who I bought it from. Google Conset 501-11 and you will find many Conset resellers.

I made the table top.

It's been going strong for 6+ years. I no longer work at home so I don't use it but my wife does her writing - about 10-15 hours week - on the treadmill.

So Express Scripts ($100B in annual sales) is going to get taken out by unit dose packaging? WalMart's pharmacy is also testing blister packs + multi-dose...I don't see how this displaces ESI...

Not that much controversy over that. HHS said most of the same this morning...I (and many folks) disagree with the premise that MarkLogic had anything to do with it. If the exact same processes and analysis were applied to a LAMP stack or an Oracle Exa-stack, the results would have likely been the same. I think the public news about the firewall sizing (4G instead of 50G) supports my claim.

So far, there have been two contractors that have been changed out - QSSI took over from CGI to lead rebuild and, recently, Terramark to be replaced by HP. Maybe this has absolutely nothing to do with not being familiar with MarkLogic.

http://kellblog.com/2013/12/01/the-pillorying-of-marklogic-w...

There was a healthcare exchange built 100% on Oracle in Oregon (Oracle team, Oracle packaged software including Siebel, Peoplesoft, IDM, Oracle integration SW + people,Oracle infrastructure, Oracle hosting). It's not going particularly well.

I don't think familiarity of technology has one thing to do with it.

I do think that MarkLogic's ability to be agile - programming (EasyApp), infrastructure (speed of transition) and performance - have a great deal to do with the speed of the team being able to deal with the software bugs above MarkLogic and the weak infrastructure around us.

(For those joining this conversation in progress, I'm a product manager at MarkLogic - I'm in charge of infrastructure like storage, performance monitoring and cloud platforms.)

From report issued Sunday morning: http://www.hhs.gov/digitalstrategy/sites/digitalstrategy/fil...

"...the root causes for these site flaws to be hundreds of software bugs, insufficient hardware and infrastructure."

The infrastructure flaws cannot be chalked up to "not learning it well enough"....There is no database - not Oracle, not PostgreSQL, not MongoDB....and not MarkLogic - that would have handled the traffic on this hardware and infrastructure.

MarkLogic is an XML document store like Oracle is a CSV file store. We store compressed trees. We require memory - like all databases - because we actually have rich indexes.

Why? Scaling by requiring massive servers is Oracle's story, not MarkLogic. We scale out on commodity servers in a cluster just fine. However, we do not magically create more capacity when adding additional VM's on top of over-subscribed network and storage systems.

We don't require proprietary shared storage systems (local, NFS, HDFS - just give us bandwidth) or proprietary networks (TCPIP please, 10G preferred, don't need FC).

Cheapest way to scale is a cluster of decent sized machines with a decent amount of IO capacity each.

{Q: What do you call a database without indexes, transactions or security? A: A file system!}

I'll repeat what our CEO said in the NYTimes article "He said MarkLogic is performing up to standard, but “the network and the storage systems are not properly sized and not properly run.”

Put any database on top of the resources that were provided and I think performance "below expectations" would have been likely.

Not really a slam at all. Customers choose MarkLogic to replace Oracle and DB2 specifically because it "handles data differently".

"Schemaless" aka "Schema on read" is the biggest difference between Only "SQL" and "Not Only SQL" systems. Scale-out on commodity hw vs. scale-up on shared storage is another. Customers often choose MarkLogic instead of other NoSQL systems because of it's ACID capabilities, ability to run multi-statement transactions between multiple databases (including Oracle and MarkLogic in the same transaction) and a multitude of enterprise capabilities from government grade security to point-in-time restore.

Read more: http://developer.marklogic.com/pubs/architecture/inside-mark...