noSQL Use Case for PLM

noSQL Use Case for PLM

I had a chance to read SQL vs. noSQL article in Linux Journal yesterday on the plane. I found it interesting and despite a bit up-level of a technical terms, beneficial for our PLM discussion. Navigate your browser on the following link and read this paper.  The noSQL story is probably one of the most dramatic in the modern history and present of data management. It considered as a heretic in the early beginning. Now noSQL comes to the point when we can talk about real advantages and disadvantages of both usage – traditional SQL and noSQL databases. So, what is the noSQL story is about?

SQL and RDBMS predictability

The story of SQL databases is very tight connected to two definitions: RDBMS and ACID. ACID means Atomicity, Consistency, Isolation, Durability. RDBMS – Relational Database Management Systems. The story about RDBMS, SQL and ACID is a story about development of transactional systems. If you develop a financial system, you want your system be predictable. You cannot take a guess about what is going on in your financial records. The same is when you schedule your manufacturing shopfloor operations. ERP leveraged RDBMS systems heabvily in their history. A vast majority of ERP systems today based on SQL /RDBMS systems.

noSQL Case

The noSQL came to us from the internet examples of the past decade such as Google, Amazon S3 and others. The fact, modern internet kids are using it added additional flavor of importance. However, what is the real case behind? Instead of using relational tables and keys, the modern noSQL databases are using simple “key-value” stores. Each piece of data going to the database is given a key and key be easy retrieved back using the same key. This portion of simplicity provides a significant value. The step beyond key-value is to have “document stores” that can access documents according to the specific key values.

PLM Use Case

Product Lifecycle Management has traditional roots in SQL databases. Started as pure data management discipline, PDM and PLM systems came to compete with other enterprise systems. It was an obvious decision back in late 1980s and beginning of 1990s that to establish a full data control you need to manage your data using RDBMS. However, this decision was taken time ago. Since then, PLM developed lots of use cases. These use cases can bring an importance of predictability down and importance of flexibility and simplicity up.

What is my conclusion? Development of PDM and PLM systems is not a simple case. The complexity of systems is high. However, some fundamental decisions and architectures of PDM/PLM were laid about twenty years ago. The urgency of reducing complexity and flexibility in PLM architectures can raise a noSQL case for PLM. Just my opinion…

Best, Oleg

Share

Share This Post

  • Vladislav Skoupski

    Oleg, I’m sorry, but with my small knowledges in Smarteam Data Model I can said that in Smarteam DB is “noSQL-style” on SQL-styled DB. I mean that all objects have unique identifier OBJECT_ID. And, as I understand, Smarteam running thru tables using links based on there OBJECT_IDs. Am I right?

  • Chase Turner

    Whoever said the PLM vendors do implement ACID guarantees in the first place, particularly in situations where there is a transactional roll-back in the face of concurrent resource contention in an overlapping set with objects in the working set to be rolled back?

    The database vendors/academics/customers created formal benchmarks for transactional price & performance relative to ACID properties exercised in well-specified business use cases ( see http://www.tpc.org ). But the PLM world has no such thing, and certainly nothing to prove a particular PLM system ever had ACID properties that could be openly examined by all. (Note: one might ask around and find there are any number of customers who have had to pound their PLM vendor into a pulp so as to force the PLM vendor to help them recover locked or unscramble mutated business data due to bad transactional errors introduced by the PLM vendor’s business locking system….)

    You are on target with respect to the value of noSQL : property set management is the heart and soul of many PLM systems. noSQL’s value should be explored further. However, I am surfacing an uncomfortable question with respect to present day PLM vendors & their implementations: although the PLM system may sit on top of a ACID capable RDBMS, that doesn’t mean that the transactional aspect of PLM system is itself ACID capable, particularly when the PLM vendor implements their own transactional locking system for business objects wrapped around a ACID-capable RDBMS.

    Without a formal PLM test suite that exercises enterprise-scale concurrent contention access for a variety of different business use cases, any PLM vendor can claim they have a good system … all the while keeping their own customers in check by quietly helping them in a pinch to save their own data from being lost by that same PLM system’s lack of ACID properties…

  • beyondplm

    Vladislav, SmarTeam data model is done on top of SQL-compliant RDBMS. You can call it non-SQL-style with huuuuge stretch. And I’d not be considered it this way. The only one thing reminds you no-SQL is a combination of ClassId and ObjectId. Rest of things is completely SQLish… Best, Oleg

  • beyondplm

    Chase, thank you for your comment! I agree with you- PLM vendors made a huge amount of tweaks on top of RDBMS and SQL-based models. In some cases, it is a heavy object-oriented layer, in some cases is flatting SQL database to the almost non-SQL state with records and IDs. The complexity of product data semantics is creating such situations. noSQL has a chance here. Best, Oleg

  • Vladislav Skoupski

    BTW, Oleg, I have old question: why ST needs class_id? object_id is unique key, there’s no one more object with same object_id and other class_id.

  • beyondplm

    ClassID used to get information about class (metadata etc.). Best, Oleg

  • There’s more to NoSQL than just key-value stores. Graph databases, such as AllegroGraph, Neo4j & FlockDB, are all NoSQL but are not key-value stores.

    My hunch (backed up by some prototyping work we’ve been doing) is that these are much better suited to PLM-type data than key-value stores as they can cope with the inherent structure present in the data.

    For the navigational and searching use cases we (ShapeSpace) are interested in, they offer significant advantages to relational databases, which would need to do expensive joins over numbers of tables to achieve the same thing. It’s also easy with a graph databases to deal with data with an evolving or ad-hoc schema – something we like when grouping similar parts based on a shape or semantic analysis.

    I wouldn’t build a full PLM system on a graph database, but there are use-cases where they have advantages.

  • beyondplm

    Andrew, thanks for the comment! Graph databases and triple stores provide advantages in some scenarios related to the work with heterogeneous information and evolving schemas. I’ve seen few very nice demos of AllegroGraph on the last Semantic Techno in SFO. And I had a chance to see it in my projects too. Best, Oleg

  • Paritosh deshmukh

    I am adding new dimension to the situation that has been addressed in this blog. With the current trend for product development analytics and the usage of content management system in conjunction with SO called PLM application. It becomes imperative to have a data model, which not only addresses pure plm play but also plays important role in Business intelligence market.

    I express my view this way because Whether it is PLM or BI or Content management industry wants to have Master data with quality and therefore PLM needs to have SQL for better management.

  • beyondplm

    Paritosh, I agree, usage of noSQL stores is more efficient in case of analytical or BI apps. However, I’m not sure understand and agree about dependencies between Master Data and SQL. can you explain? Tnx, Oleg