Unsupported Features

  • $natural sort is not supported in this release.
  • mongorestore with the –dbpath is not supported. This mongorestore option writes bson files directly to the file system. SonarW’s files have a columnar format and bson files cannot be used by SonarW directly - they must be ingested by the database engine first.
  • SonarW does not support geoHaystack index and the geoSearch admin command that uses it.
  • SonarW does not support any CRS in indexing GeoJSON data, it uses the default CRS.
  • SonarW does not support compound geo indexes with other geo indexes.
  • SonarW does not support compound text indexes.
  • SonarW does not support the ‘moderate’ level in document validation. Use only ‘strict’ or ‘off’.
  • Changing $CURRENT in Aggregation Expressions is not supported.
  • Histograms in views are not supported.

Dates

SonarW supports dates after Unix epoch. Correct results for dates before epoch are not guaranteed.

No-Ops

The following commands and flags are supported (and will be run) by SonarW but are implemented as no-ops and do nothing in SonarW:

  • $cmd.system.unlock
  • $isolated
  • $hint
  • cursor.min()
  • cursor.max()
  • Capped collections
  • fsync
  • $maxScan / cursor.maxScan()
  • collMod
  • allowDiskUse
  • Write Concern
  • server / client sessions

MongoDB Indexes

SonarW does not support indexes in the MongoDB sense; it indexes every field automatically using a Big Data index optimized for very large data size, without the need for large memory footprint. Sonar does not limit the size of an indexed field.

The only exceptions are the Text Index and Word Index features.

Known Differences from MongoDB

  • SonarW does not preserve the order of inserted fields and follows the JSON definition that an object is an ordered set of name/value pairs. Starting in MongoDB 2.6 MongoDB actively attempts to preserve the field order in a document. Since SonarW is a column store, preserving order is impossible.
  • distinct in SonarW behaves like a $group. If a document has an array of strings, SonarW will add this array as a distinct element, while MongoDB will add each string in the array as an element to the array.
  • MaxTimeMS is used to limit the time a query takes before starting to return results. Once data is returned (e.g. in a cursor) no limit is placed on the time the client can do a getMore, even when very long result sets are needed.
  • As a data warehouse, SonarW processes large batches of data; even if a client requests a small cursor batch size, more results will be readily available.
  • To provide high update throughput, SonarW implements update as a drop-insert, and does not lock the collection during updates; other clients querying the collection may see temporary results, until the update finishes.
  • Mongo will allow a bad view to be added to system.views, and then it will fail subsequent commands (e.g. list collections) on that database. SonarW does not allow insertion of a bad / misconfigured view.
  • SonarW allows ‘$’ in field names, including as a pre-fix for top-level fields.