News Categories
(6)Press Releases (14)MarkLogic World (28)Big Data (37)Uncategorized (7)Dynamic Publishing (18)Agile Development (1)cloud (7)Hadoop (30)NoSQL (9)semantics (42)Enterprise NoSQL (1)HTML5 (3)Mobile (1)data enrichment (4)defense (1)geospatial (4)intelligence (4)search (4)use case (12)Analytics (12)ACID compliant (5)Defense (8)Search (3)alerting (1)query (1)schema (1)variety (1)velocity (6)Security (8)Content Platform (1)Migration (1)Serialized Search (1)Springer (7)Financial Services (1)Fraud (1)Big Data Nation Dallas (1)Big Data Nation (1)Chris Anderson (2)Fernando Mesa (1)Reed Construction Data (1)Reed Elsevier (1)Tony Jewitt (2)Situational Awareness (2)Dan McCreary (1)LexisNexis (1)Mark Rodgers (1)David Gorbet (1)David Leeming (1)MUGL (5)Publishing (1)Royal Society of Chemistry (1)RSC (1)Science (1)User Group (2)Intel (1)Sony (2)Amir Halfon (1)AML (1)Anti-Money Laundering (1)BDN Boston (1)Temis (4)DAM (1)Condé Nast (1)Digital Asset Management (1)Henry Stewart (4)Book Publishing (1)XQuery (1)Direct Digital (1)Typeswitch (1)Permissions (1)AIP (1)Digital Media (1)James Wonder (1)mission-based publishing (1)STM associations (2)STM publishing (8)Media (4)Media & Marketing (1)Facets (1)mongoDB (9)Semantic Web (1)Amazon Web Service (1)Cloud (1)BBC (2)MarkLogic 7 (1)Mike Bowers (1)Sanjay Anand (1)Software Upgrade (1)Zynx Health (1)Multi-Version Concurrency (7)Marketing (3)The Real Scoop (1)Frank Rubino (1)Operational Trade Store (2)Linked Data (1)Philip Fennell (2)RDF (1)Adam Fowler (1)Range Indexes (1)range indexing scoring (2)Journey to Sanity (1)Jason Hunter (1)Loading As Is (1)MapReduce (1)HDFS (1)ASTM (2)Learning Management System (2)LMS (1)Intelligence (7)Healthcare (1)Enterprise Reference Data management (1)Reference data (2)Tableau (2)JSON (3)AngularJS (2)jQuery (1)Education (1)LRS (1)TinCan (1)Events (1)San Francisco (9)Data Management (1)MarkLogic World Tour (2)Government (1)Decision Support (6)Semantics (2)hiring (2)jobs (2)skill set (3)REST API (2)C++ REST Wrapper (2)narrative (2)Polling (2)Unstructured (2)Early Access (1)Open Source (1)free developer license (1)Java Client API (1)open source (1)proprietary (2)metadata (1)Women in Technology (1)Grace Hopper (1)Mary Hostege (1)frankfurt book fair (1)Klopotek (1)Larry (1)OpenWorld (1)Oracle (1)DaaS (1)Data as a Service (1)women in technology (2)ACID transactions (2)Government-grade security (2)rapid application development (2)RDBMS (4)Community (2)Bitemporal (3)MarkLogic 8 (1)Turkey (1)Santa's List (1)data integration (1)geospatial data (1)Patient 360 (1)EHR interoperability (1)HIE (1)semantic data (1)semantic interoperability (1)technology interoperability (1)Time-Series (2)Angular JS (1)Ember (1)JEE (1)document database (1)NBC (1)SNL app (2)Martin Fowler (2)microservices (1)polyglot persistence (1)polyglot persistance (2)Risk Management (1)Samplestack (1)Java (1)multi-statement transactions (1)product management (1)samplestack (1)Innovation (1)MarkLogic History (1)Timeline
Supported Server Versions
Version Original Release Date Current Release End of Life Date
MarkLogic Server 8.0 February 6, 2015 8.0-1 In Circulation
MarkLogic Server 7.0 November 14, 2013 7.0-5 In Circulation
MarkLogic Server 6.0 September 12, 2012 6.0-5.3 In Circulation
MarkLogic Server 5.0 October 4, 2011 5.0-6.1 May 8, 2015
Latest Updates
Looking Back on 12 Years of Constant Innovation
Posted by Matt Allen on 19 March 2015 12:00 PM

Enterprise-Ready in Version 1

It’s not easy to be both innovative and enterprise-ready from the start, but MarkLogic was. Initially launched as Cerisent XQE Server 1, the first version of MarkLogic carried patents for its innovative way of storing data, and also included ACID transactions, application services, and backup/restore.

Very few technologies are enterprise-ready in version 1, let alone version 2, 3, or 4. Even Oracle didn’t even have many of its enterprise capabilities such as role-based security and backup recovery until version 7, more than a decade after they first started selling software.

Yes, the software world moves at a faster pace right now, but that often comes with a price. In the effort to get to market faster, database companies have often decided to focus first on doing many of the easy things. Most NoSQL databases just try and ignore ACID transactions and security, even though they know those things are important. Unfortunately, it is much harder to go back and add in the enterprise features later on, and so it comes as no surprise when we see a bunch of large database companies making acquisitions in order to fill the gaps where they made sacrifices early on.

Having a strong foundation is critical, and MarkLogic has had that from the start. And, in the past decade, MarkLogic has proven itself in hundreds of enterprise organizations that require an enterprise-class database.

Thriving for Over a Decade

How many database companies are over ten years old? The database market doesn’t have room for inferior technologies. There is a reason that the incumbent leaders – Oracle, IBM, and Microsoft – have remained dominant for so long.

Most organizations don’t take their investment in a new database lightly, and MarkLogic has been able to continue to prove to be a valuable asset to organizations again and again. In fact, MarkLogic’s first customer still runs enormous clusters with hundreds of Terabytes of data on MarkLogic. And, since first launching, that organization and hundreds of others have continued to upgrade and use the innovative new features that MarkLogic comes out with in every new release.

MarkLogic’s founder, Christopher Lindblad, created an innovative, patented technology over a decade ago. And now, over 12 years later, innovation is still happening every day. In our last release, we launched a feature called Bitemporal – and right now MarkLogic is the only NoSQL database to have this feature. We’re also the only NoSQL database that has an integrated triple store for storing documents, data, and triples in the same system.

Take a look at how far we’ve come…


The Next Twelve Years

Whenever we talk about MarkLogic with people for the first time, we always end with the question, “What Will You Reimagine?” This question isn’t just for customers though. It’s also for us.

The product team is already planning for the next release, MarkLogic 9, and we are again reimagining what can be done to make MarkLogic even better. And this is when we look to you, our customers, to join us and to work with us in the effort to continue our long track record of innovation in building features and solutions that matter. (And I’m actually giving you an open invitation here, we take suggestions from customers for new features very seriously, so please get in touch!)

Change happens fast and we don’t expect to stop here. MarkLogic is still a young company, and we look forward to growing even stronger over the next twelve years.

Looking Back on 12 Years of Constant Innovation from MarkLogic.

Read more »

Schema Agnosticism: What It Is and Why You Should Care
Posted by Paul Hoehne on 16 March 2015 11:42 AM

There is a difference between being schema agnostic and schema free and it isn’t just a pedantic one. As a MarkLogic user, even a non-technical user, you should understand the distinction …

MarkLogic’s flexible support for schemas is an important feature that can help maintain data quality while avoiding the costly burden of complex enterprise data models. If you read the MarkLogic marketing materials, you’ll encounter the phrase “schema agnostic.” Many other NoSQL vendors however describe themselves as “schema free,” and as a result MarkLogic is sometimes mistakenly referred in this way as well. The two phrases are not synonyms — and I’ll explore the distinctions between the two and why you should care.

What is a Schema?

A schema is an enforceable set of rules about the structure of a database. They are used to help maintain data quality, which is an abstract attribute of data that indicates the degree to which data is consistent and semantically correct. For example, a database might define a customer record as a customer id, a name, and the date the record was created. Relational databases describe this using DDL (Data Definition Language), colloquially referred to as “create table” statements. XML has a couple of schema definition languages but the most used one is called XML Schemas. The database uses the schema to reject data that doesn’t meet the schema’s requirements. A database with high data quality will provide more reliable and actionable information than a database with poor data quality.

Why Are Schemas Used?

Originally, databases were largely schema-free. Unfortunately this did not always work out well in large, enterprise databases. Different programmers would make different assumptions about the expected contents of the database. A maintenance program might break the nightly invoice batch by adding invalid or unexpected data. Consequently, schemas became mandatory in relational databases, which came to dominate the database landscape in the 1980s and 1990s. Mandatory schema conformance met both a data quality need and allowed relational databases to efficiently store data on the limited hardware available.

The need for strict schema enforcement became enterprise orthodoxy. Developers have recently challenged that orthodoxy because designing, maintaining and evolving schemas over time is a complex and costly burden. Changes in large production database often require significant preparation and planning. In many cases relational databases became sclerotic, with even poor structure being enforced by the administrators, who are pressed into service as gatekeepers, stopping or slowing changes because any change is perceived as inherently risky. In an era when significant opportunities may arise and disappear in the span of a few months, a difficult to change, complex data model may do more damage than just increase development costs.

Many believe that strict schema enforcement was actually a band-aid over the real issue of multiple applications reading and writing shared data. Their solution is to abandon shared data and uniformly encapsulate data behind services. While I believe micro services offer tremendous potential, a service-only approach isn’t always feasible. The most common problems are interoperability in service frameworks for advanced features such as distributed transactions and the cadre of legacy applications that currently share data. Also, data quality problems can still arise when bugs or poorly considered features introduce unwanted artifacts into the database.

What is Schema Free?

A schema free database is not bound by any schema rules outside of correct syntax. While it does diminish the need for database specialists to tune a schema, and for paid gatekeepers to protect that schema, data quality can quickly deteriorate. A schema free database has no mechanism with which to enforce the rules of good structure at the database level. Some development libraries for those databases provide a way to enforce a structure in the application code. However, this is voluntary and two applications may not have share a consistent set of rules. Not being able to enforce structure at the database level may be just as limiting as requiring that structure must always be enforced.

What is Schema Agnostic?

Schema agnostic databases are not bound by schemas — but are aware of the schemas – and specific schemas can be enforced at at the database level if desired/necessary. Moreover, XML Schemas, used by MarkLogic, can serve to auto-generate libraries that express that structure in common languages such as Java. The distinction is MarkLogic does not require you to adopt a schema – but if you have one (or many) and you wish to enforce it — you can. You can avoid the exercise of developing and enforcing a schema when it just isn’t warranted. It is also possible to enforce schema constraints in certain environments, such as in test environments, to validate that applications adhere to the prescribed data model prior to entering production. In a nutshell, a schema agnostic database allows you to enforce a structure when the business needs indicate that it’s necessary but do not require it when the schema provides little value.

What is the Bottom Line Impact?

All of this discussion, at a high “nosebleed” level, has an impact on cost and agility. A database often outlives the applications that depend on it. A poorly crafted user interface may stay for years, but a database can haunt an enterprise for decades. The relational approach of mandatory schemas can lead to longer, more costly, and complex development efforts. The other extreme, of never enforcing structure, can quickly lead down a path of poor data quality and a database of low value data. Neither extreme is really tenable or appropriate in the long run. Clearly a middle ground solution that allows schemas to be enforced only when necessary is better – and that is exactly what MarkLogic offers.

Schema Agnosticism: What It Is and Why You Should Care from MarkLogic.

Read more »

Copyright © 2015 MarkLogic Corporation. All Rights Reserved. MARKLOGIC® is a registered trademark of MarkLogic Corporation.   Terms of Use  |  Privacy Policy  |  Careers  |  Sitemap