{"id":14249,"date":"2023-04-04T13:27:26","date_gmt":"2023-04-04T20:27:26","guid":{"rendered":"https:\/\/www.couchbase.com\/blog\/?p=14249"},"modified":"2025-06-13T23:00:08","modified_gmt":"2025-06-14T06:00:08","slug":"updating-sensor-data-exploring-couchbases-multi-model-options","status":"publish","type":"post","link":"https:\/\/www.couchbase.com\/blog\/updating-sensor-data-exploring-couchbases-multi-model-options\/","title":{"rendered":"Updating Sensor Data: Exploring Couchbase’s Multi-Model Options"},"content":{"rendered":"

Couchbase has become a popular choice for <\/span>IoT use cases<\/span><\/a>, thanks to its flexible <\/span>multi-model<\/span><\/a> data management capabilities.<\/span><\/p>\n

Recently, I was working with a customer in the cruise industry that had a unique challenge – they needed Couchbase to receive and store frequent updates from many sensors that record readings on their fleet of ships. These readings could potentially come to Couchbase out of chronological order. How can they ensure that a new sensor reading could only be stored if it had a later timestamp than the previous reading?<\/span><\/p>\n

Each sensor has a unique key that corresponds to the latest sensor reading. A reading from 10:43:00 AM could not overwrite a reading from 10:42:30 AM, even if the latter had been received later. Below are some sample readings and their order of processing (note the timestamps are not necessarily in chronological order):<\/span><\/p>\n

id: \"C-DI_Nautical_Speed\"\r\n{\r\n\u00a0 \u00a0 \"speed\": 15,\r\n\u00a0 \u00a0 \"unit\": \"knots\",\r\n\u00a0 \u00a0 \"timeStamp\": \"2023-03-10 10:43:00 AM\"\r\n}\r\n\r\nid: \"C-DI_Nautical_Speed\"\r\n{\r\n\u00a0 \u00a0 \"speed\": 15.1,\r\n\u00a0 \u00a0 \"unit\": \"knots\",\r\n\u00a0 \u00a0 \"timeStamp\": \"2023-03-10 11:43:00 AM\"\r\n},\r\n\r\nid: \"C-DI_Nautical_Speed\"\r\n{\r\n\u00a0 \u00a0 \"speed\": 14.9,\r\n\u00a0 \u00a0 \"unit\": \"knots\",\r\n\u00a0 \u00a0 \"timeStamp\": \"2023-03-10 10:42:30 AM\"\r\n}<\/pre>\n
In this blog post, we\u2019ll explore how Couchbase\u2019s multi-model options can help tackle this scenario and efficiently manage sensor data updates.<\/span><\/p>\n
What is Multi-Model?<\/h2>\n
Couchbase is perhaps the original multi-model database, as it combines memory-first caching with JSON data persistence to provide a flexible approach to data management. Couchbase can handle multiple data types, such as structured, semi-structured, and unstructured data, in the same database instance.<\/span><\/p>\n
Over time, Couchbase has added <\/span>SQL++<\/span><\/a>, <\/span>Full Text Search (FTS)<\/span><\/a>, <\/span>Eventing<\/span><\/a>, <\/span>Analytics<\/span><\/a> tools: multiple models for accessing, indexing, and interacting with the same pool of data. This multi-model approach can make Couchbase more flexible than traditional databases, but it can also require a little more thought about tradeoffs compared to those legacy systems (that might only have one way to interact with data).<\/span><\/p>\n
Multi-Model Options for Updating Sensor Readings<\/h2>\n
When it comes to updating sensor readings for this use case in Couchbase\u2019s multi-model database, there are several approaches to consider:<\/span><\/p>\n
    \n
  1. \n
      \n
    1. Key-value API with optimistic or pessimistic locking<\/span><\/li>\n
    2. Key-value API with ACID transaction<\/span><\/li>\n
    3. SQL++ UPDATE statement<\/span><\/li>\n
    4. Eventing OnUpdate function<\/span><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
      All of these options have their own set of advantages and trade-offs in terms of performance, complexity, and requirements. Choosing the best approach will depend on factors such as the size and frequency of the updates, the level of concurrency, and the overall performance requirements.<\/span><\/p>\n
      Ultimately, the best approach can only be determined through real-world testing with live data or a good approximation of live data. By examining the trade-offs and experimenting with the different options, developers can identify the most effective method for updating sensor readings in Couchbase\u2019s multi-model database.<\/span><\/p>\n
      It\u2019s important to note that in many of these scenarios, we assume that the sensor document already exists (which will be the most common scenario in a steady state). When that\u2019s not the case, we can change the replace<\/em> or update<\/em> operation to upsert<\/em>\u00a0to ensure that the document is created if it does not exist. (Alternatively, you could “seed” the collection with a document for each sensor).<\/span><\/p>\n
      All that being said, let\u2019s examine each possibility.<\/span><\/p>\n
      Key-value API with Optimistic or Pessimistic Locking<\/h2>\n
      One approach to updating sensor readings in Couchbase\u2019s multi-model database is through optimistic or pessimistic locking. This locking mechanism, which has been present in Couchbase for a long time, uses a technique called <\/span>CAS (compare and swap)<\/span><\/a> to ensure conditional updates of individual documents.<\/span><\/p>\n
      The CAS value is an arbitrary number that changes every time a document changes. By matching CAS values, developers can conditionally update sensor data with minimal overhead. In this section, we will explore how optimistic and pessimistic locking can be used for this sensor data use case.<\/span><\/p>\n
      Optimistic Locking<\/h3>\n
      Optimistic locking is a straightforward approach to updating sensor data in Couchbase, with only three steps required:<\/span><\/p>\n
      The <\/span>first step<\/b> involves retrieving the document by key, which includes the document value and its metadata (including the CAS value).<\/span><\/p>\n
      Once retrieved, the <\/span>second step<\/b> is to check if the timestamp is older than the incoming timestamp.<\/span><\/p>\n
      If it is, the <\/span>third step<\/b> involves replacing the document with the new value and submitting the CAS value with it.<\/span><\/p>\n
      Here\u2019s where the “optimistic” part comes in. If the CAS values match, the operation is successful, and the sensor data is updated. However, if the CAS value doesn\u2019t match, it means that the sensor data has been updated (by some other thread\/process) since the last read operation. In this case, you have the option to <\/span>retry the operation<\/b> from the beginning. If you don\u2019t expect the specific sensor document to get updated frequently, then optimistic locking is the way to go (as retries would be infrequent).<\/span><\/p>\n
      Here\u2019s an example of optimistic locking with simple retry logic:<\/span><\/p>\n
      \/\/ get existing sensor reading\r\nvar currentDoc = await _collection.GetAsync(sensorId);\r\nvar currentDocCas = currentDoc.Cas;\r\nvar currentReading = currentDoc.ContentAs<NauticalSpeed>();\r\n\r\n\/\/ check timestamps\r\nif (newSensorReading.TimeStamp > currentReading.TimeStamp)\r\n{\r\n\u00a0 \u00a0 \/\/ incoming reading is newer, update the record\r\n\u00a0 \u00a0 Console.WriteLine(\"Incoming sensor reading is newer. Updating.\");\r\n\u00a0 \u00a0 var retries = 3;\r\n\u00a0 \u00a0 while (retries > 0)\r\n\u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 try\r\n\u00a0 \u00a0 \u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 await _collection.ReplaceAsync(sensorId, newSensorReading, options => options.Cas(currentDocCas));\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 return;\r\n\u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 \u00a0 \u00a0 catch (CasMismatchException)\r\n\u00a0 \u00a0 \u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 Console.WriteLine($\"CAS mismatch. Retries remaining: {retries}\");\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 retries--;\r\n\u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 }\r\n\u00a0 \u00a0 Console.WriteLine(\"Retry max exceeded. Sensor reading was not updated.\");\r\n}\r\nelse\r\n{\r\n\u00a0 \u00a0 Console.WriteLine(\"Incoming sensor reading is not new. Ignoring.\");\r\n\u00a0 \u00a0 \/\/ incoming reading is not newer, so do nothing\r\n\u00a0 \u00a0 \/\/ (or possibly update a log, or whatever else you want to do)\r\n}<\/pre>\n
      Pessimistic Locking<\/h3>\n
      Pessimistic locking<\/span><\/a> is another way to approach the same problem. Like optimistic locking, it has three steps, but with some slight differences.<\/span><\/p>\n
      The <\/span>first step<\/b> is to <\/span>get and lock<\/span><\/i> a document by key, making note of the CAS value. Unlike optimistic locking, where the document is simply read, in pessimistic locking, the document is explicitly locked. This means that no other process can make changes to the document until it becomes unlocked.<\/span><\/p>\n
      In the <\/span>second step<\/b>, just like optimistic locking, the timestamp is checked to see if it\u2019s older than the incoming timestamp.<\/span><\/p>\n
      If it is, then in the <\/span>third step<\/b>, the document is replaced with the new value and submitted with the CAS value.<\/span><\/p>\n
      In step 1 of pessimistic locking, you also have to specify a timeout window. Why? It\u2019s possible that step 3 might never happen due to an error or crash, and the document needs to eventually unlock.<\/span><\/p>\n
      If you expect the sensor document to be updated a lot, pessimistic might be the better approach. But because of the lock, there could be a reduced latency in other processes waiting for the document to become unlocked.<\/span><\/p>\n
      To illustrate, here\u2019s an example of pessimistic locking in action:<\/span><\/p>\n
      \/\/ get current sensor data\r\nvar maxLockTime = TimeSpan.FromSeconds(30);\r\nvar currentDoc = await _collection.GetAndLockAsync(sensorId, maxLockTime);\r\nvar currentDocCas = currentDoc.Cas;\r\nvar currentReading = currentDoc.ContentAs<NauticalSpeed>();\r\n\r\n\/\/ check timestamps against new reading\r\nif (newSensorReading.TimeStamp > currentReading.TimeStamp)\r\n{\r\n\u00a0 \u00a0 \/\/ incoming reading is newer, update the record\r\n\u00a0 \u00a0 Console.WriteLine(\"Incoming sensor reading is newer. Updating.\");\r\n\u00a0 \u00a0 await _collection.ReplaceAsync(sensorId, newSensorReading, options => options.Cas(currentDocCas));\r\n\u00a0 \u00a0 return;\r\n}\r\nelse\r\n{\r\n\u00a0 \u00a0 await _collection.UnlockAsync(sensorId, currentDocCas);\r\n\u00a0 \u00a0 Console.WriteLine(\"Incoming sensor reading is not new. Ignoring.\");\r\n\u00a0 \u00a0 \/\/ incoming reading is not newer, so do nothing\r\n\u00a0 \u00a0 \/\/ (or possibly update a log, or whatever else you want to do)\r\n}<\/pre>\n
      CAS Locking Tradeoffs<\/h3>\n
      When it comes to CAS locking, there are trade-offs to consider. Optimistic locking works well when conflicts are infrequent, but you\u2019ll need to implement appropriate retry logic to handle possible retries.<\/span><\/p>\n
      To help with this tradeoff, more advanced or specialty retries could be used. For instance, in this use case, it may be acceptable to “give up” and discard an incoming sensor reading if there have been a lot of retries and\/or the reading is very old.<\/span><\/p>\n
      Pessimistic locking, on the other hand, is a “safer” approach but requires a clear understanding of the performance implications of locking. Locking can increase latency in other processes that need to wait for the document to become unlocked.<\/span><\/p>\n
      ACID transaction<\/h2>\n
      Another potential solution to the sensor update problem is using an ACID transaction. This approach may be overkill for updating a single document in this use case, but it could be useful in different use cases where multiple documents need to be updated atomically.<\/span><\/p>\n
      A challenge with sensor data is that it can be coming in at a fast rate. In the time between checking the current data and updating with incoming sensor data, another reading could be coming in. To avoid this issue, an ACID transaction can be used to conditionally update data.<\/span><\/p>\n
      The sample code below demonstrates how to use an ACID transaction to update a sensor document. The transaction ensures that only one update operation can occur at a time per sensor, preventing multiple incoming sensor readings from interfering with each other.<\/span><\/p>\n
      var transaction = Transactions.Create(_cluster, TransactionConfigBuilder.Create()\r\n\u00a0 \u00a0 .DurabilityLevel(DurabilityLevel.None)); \/\/ set to 'none' because I'm using a single-node dev cluster\r\n\u00a0 \u00a0 \/\/ for more details see: https:\/\/docs.couchbase.com\/dotnet-sdk\/current\/howtos\/distributed-acid-transactions-from-the-sdk.html\r\n\r\nawait transaction.RunAsync(async (context) =>\r\n{\r\n\u00a0 \u00a0 \/\/ get existing sensor reading\r\n\u00a0 \u00a0 var currentDoc = await context.GetAsync(_collection, sensorId);\r\n\u00a0 \u00a0 var currentReading = currentDoc.ContentAs<NauticalSpeed>();\r\n\r\n\u00a0 \u00a0 \/\/ check timestamps\r\n\u00a0 \u00a0 if (newSensorReading.TimeStamp > currentReading.TimeStamp)\r\n\u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \/\/ incoming reading is newer, update the record\r\n\u00a0 \u00a0 \u00a0 \u00a0 Console.WriteLine(\"Incoming sensor reading is newer. Updating.\");\r\n\u00a0 \u00a0 \u00a0 \u00a0 await context.ReplaceAsync(currentDoc, newSensorReading);\r\n\u00a0 \u00a0 }\r\n\u00a0 \u00a0 else\r\n\u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 Console.WriteLine(\"Incoming sensor reading is not new. Ignoring.\");\r\n\u00a0 \u00a0 \u00a0 \u00a0 \/\/ incoming reading is not newer, so do nothing\r\n\u00a0 \u00a0 \u00a0 \u00a0 \/\/ (or possibly update a log, or whatever else you want to do)\r\n\u00a0 \u00a0 }\r\n});<\/pre>\n
      ACID Transaction Trade-offs<\/h2>\n
      The key-value API should be used whenever possible to maximize performance. However, using a distributed ACID transaction in Couchbase will come with some overhead because of the additional key-value operations executed (behind the scenes) to coordinate the transaction. Since data in Couchbase is automatically distributed, operations will likely be coordinated across a network to multiple servers.<\/span><\/p>\n
      One benefit of using an ACID transaction over a CAS operation is that the Couchbase Transaction libraries already have sophisticated retry logic built into them. This can be a way to avoid writing your own retry logic. Additionally, an ACID transaction is recommended (probably required, in fact) if a use case involves updating multiple sensor documents.<\/span><\/p>\n
      SQL++ Update Operation<\/h2>\n
      Another approach to performing conditional updates is to use a SQL++ UPDATE query.<\/span><\/p>\n
      Here\u2019s an example implementation:<\/span><\/p>\n
      var retries = 3;\r\nwhile (retries > 0)\r\n{\r\n\u00a0 \u00a0 try\r\n\u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 await _cluster.QueryAsync<dynamic>(@\"UPDATE sensordata s\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 USE KEYS $sensorId\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 SET s.speed = $newSpeed, s.unit = $newUnit, s.timeStamp = $newTimeStamp\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 WHERE DATE_DIFF_STR($newTimeStamp, s.timeStamp, 'millisecond') > 0\", options =>\r\n\u00a0 \u00a0 \u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 options.Parameter(\"sensorId\", sensorId);\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 options.Parameter(\"newSpeed\", sensorReading.Speed);\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 options.Parameter(\"newUnit\", sensorReading.Unit);\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 options.Parameter(\"newTimeStamp\", sensorReading.TimeStamp);\r\n\u00a0 \u00a0 \u00a0 \u00a0 });\r\n\u00a0 \u00a0 \u00a0 \u00a0 return;\r\n\u00a0 \u00a0 }\r\n\u00a0 \u00a0 c atch (CasMismatchException)\r\n\u00a0 \u00a0 {\r\n\u00a0 \u00a0 \u00a0 \u00a0 Console.WriteLine($\"UPDATE CAS mismatch, tries remaining: {retries}\");\r\n\u00a0 \u00a0 \u00a0 \u00a0 retries--;\r\n\u00a0 \u00a0 }\r\n}\r\nConsole.WriteLine(\"Max retries exceeded, sensor not updated\");<\/pre>\n
      (By the way, using an epoch timestamp will likely provide better performance).<\/span><\/i><\/p>\n
      As you might have guessed from the code, the SQL++ query is actually using CAS behind the scenes, just as is being done with the KV API example earlier.<\/span><\/p>\n
      SQL++ tradeoffs<\/h2>\n
      The SQL++ approach for conditional updates does come with some trade-offs. Although the <\/span>USE KEYS<\/span><\/em> clause helps to eliminate the need for an index, the query still needs to be parsed by the query service, which <\/span>involves many steps<\/span><\/a>. This can put added pressure on the system if other components are already using the query service.<\/span><\/p>\n
      Overall, since the SQL++ approach is very similar to the KV API with the added overhead of parsing the query, it may not be the best choice unless you have a specific need for complex logic expressed in SQL++ or if using the KV API is not an option.<\/span><\/p>\n
      Eventing<\/h2>\n
      The last approach I want to cover is the use of Eventing.<\/span><\/p>\n
      Eventing in Couchbase consists of writing JavaScript functions that respond to data change events asynchronously and deploying them to the Couchbase cluster.<\/span><\/p>\n
      For this particular use case, I think that using a “staging” collection as a location for the sensor readings initially is the way to go. Here\u2019s the sequence:<\/span><\/p>\n
        \n
      1. \n
          \n
        1. Incoming sensor readings are written to a “staging” collection.<\/span><\/li>\n
        2. An Eventing OnUpdate<\/em> function responds to new sensor readings.<\/span><\/li>\n
        3. The OnUpdate<\/em> function checks timestamps against the corresponding document in the “current” collection<\/span><\/li>\n
        4. If timestamp is more current, the document in the “current” collection gets updated.<\/span><\/li>\n<\/ol>\n<\/li>\n<\/ol>\n
          OnUpdate<\/span><\/em> will run when a document is created <\/span>or<\/span><\/i> updated, so it\u2019s okay to leave the old document in staging (this simplifies the eventing code). Also, a TTL can be set on the collection, so that if a sensor reading isn\u2019t updated in a while, it will be automatically cleaned up.<\/span><\/p>\n
          Here\u2019s an example of an eventing function that works with this design:<\/span><\/p>\n
          function OnUpdate(doc, meta) {\r\n\u00a0 \u00a0 \/\/ Only process documents with a \"timestamp\"\r\n\u00a0 \u00a0 if (doc.timestamp) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \/\/ Extract timestamp and sensor ID from the staged document\r\n\u00a0 \u00a0 \u00a0 \u00a0 var stagedTimestamp = doc.timestamp;\r\n\r\n\u00a0 \u00a0 \u00a0 \u00a0 \/\/ note that this will loop indefinitely\r\n\u00a0 \u00a0 \u00a0 \u00a0 \/\/ but you can also limit it to a certain number of reties if you wish\r\n\u00a0 \u00a0 \u00a0 \u00a0 while(true) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ Get the current document for the same sensor ID from the \"destination\" collection\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 var currentDoc = dst_col[meta.id];\r\n\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ If there is no current document, or the staged timestamp is later than the current timestamp, update the current document\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 if (!currentDoc || stagedTimestamp > currentDoc.timestamp) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ dst_col is a READ+WRITE ALIAS\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 dst_col[meta.id] = doc;\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ the whole document is overwritten, but you can also choose to override certain fields if you wish\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ src_col is a READ ALIAS\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 var result = couchbase.get(src_col, meta);\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 if (result.success) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 if (result.meta.cas == meta.cas) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ the document was unchanged in the stage collection we are done\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 break;\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 doc = result.doc;\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 stagedTimestamp = doc.timestamp;\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 } else {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 if (result.error.key_not_found) {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ this might be okay, assuming 'staging' collection gets cleaned up or has a TTL\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \/\/ again, this will depend on what kind of retry logic you have\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 break;\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 } else {\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 log('failure could not read stage adv. get: id',meta.id,'result',result);\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 \u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 \u00a0 \u00a0 }\r\n\u00a0 \u00a0 }\r\n}<\/pre>\n
          And here is the config for that eventing function:<\/span><\/p>\n
          \"Eventing<\/p>\n
          Eventing Trade-offs<\/h2>\n
          Again, notice that an optimistic CAS lock is being used in this code. In fact, you could almost say that this was a JavaScript version of the code using the KV API earlier.<\/span><\/p>\n
          One key difference is that this function is running on the Couchbase cluster itself. And this is the key benefit to eventing: no matter where the sensor data is coming from, Couchbase\u2019s Eventing function will ensure that it gets processed. It\u2019s keeping the logic close to the data. If you have two or more clients that use the KV API instead, that means you need two or more implementations of the same code. This can lead to problems when logic changes, as it will need to be updated in multiple places.<\/span><\/p>\n
          However, just as with SQL++, Eventing has some overhead that\u2019s involved. In this case, multiple collections, and the eventing service itself. Typically this could involve an additional node of Couchbase in production. Further, Eventing is not currently available in Couchbase Server Community.<\/span><\/p>\n
          Summary<\/h2>\n
          Couchbase is a multi-model database that offers options and tradeoffs for your use case. In this post, the use case of sensor data updates was covered with 4 different data access patterns, each with their pros and cons:<\/span><\/p>\n