12 results found

1. Add expression indexes

   An expression index is one where the value being indexed is the result of an expression, like lower casing a string.

   http://en.wikipedia.org/wiki/Expression_index
   http://www.postgresql.org/docs/8.1/static/indexes-expressional.html

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

2. Allow multiple text indexes per collection

   MongoDb only allow one text index by collection, in contrast of other index types.

   This is a limitation that makes it difficult to develop projects with search functionality, for example, if you want to add a text search for advanced users on all fields and a public search on a subset of fields, there isn't a simple and performant way to solve it.

   Many developers end up using other products like elastic search, or creating additional collections and using lookup, or using preg_reg or building smart indexes when the creation of multiple text indexes per collection would allow a quick, easy, and efficient solution for many of these scenarios.
    
   This would be a good feature for mongodb :)

   MongoDb only allow one text index by collection, in contrast of other index types.

   This is a limitation that makes it difficult to develop projects with search functionality, for example, if you want to add a text search for advanced users on all fields and a public search on a subset of fields, there isn't a simple and performant way to solve it.

   Many developers end up using other products like elastic search, or creating additional collections and using lookup, or using preg_reg or building smart indexes when the creation of multiple text indexes per collection would allow a quick,… more

   4 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

3. bloom filter index

   https://www.percona.com/blog/2019/06/14/bloom-indexes-in-postgresql/

   I think having an option to use bloom filter indexes could provide for better performance when compared to compound indexes and eliminate the need for having multiple indexes. It would likely require tuning still, but with very large data sets this could be much less expensive.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

4. Support compound TTL index

   Right now you can only do a single field TTL index. I would like a put a TTL on a compound index.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

5. Rename an existing index

   Allow for the possibility of renaming an existing index, without having to drop and recreate it.

   Let us say a unique index exists in production, it might not be possible to safely drop it. Yet the index name might not be ideal.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

6. Automatic Indexes

   MongoDB can already suggest useful indexes. Why not take the next step and allow MongoDB to autonomously create and manage indexes. Ideally it will automatically maintain the indexes over time as the structure and usage of the database changes.

   3 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   1 comment  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

7. Add numerically-ordered index feature which forces a field to maintain ordering

   I would like MongoDB to add better support for ordered lists across documents in a collection. This feature would allow the user to designate a field such as "position", and the DB would ensure the values of that field across documents remain in a monotonically-increasing integer sequence 0, 1, 2, 3, ... N.

   I am the maintainer of a Ruby library called "Mongoid Orderable". This library makes numerically ordered field across documents. I'd like to ask MongoDB to investigate moving the functionality of this library to the server.

   What use case would this feature/improvement enable?

   This feature would be useful in a wide-variety of real world applications; ordered lists are extremely common. In my app (standard SaaS related to restaurant management) I have at least 20 instances of such ordered lists.

   Suggested implementation

   I propose to do this using a new "ordered" index type.

   For example, suppose my application has many Car documents, and I want to maintain the "position" of the Cars in a consistent order for each Dealer.

   I add the following index to the Car collection:

   Cars -> createIndex({ dealer_id: 1, position: 1 }, { ordered: 1 })

   Then in my Car collection, I see:

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: **, position: 1
   Car C -> dealer_id: **, position: 2
   Car D -> dealerid: yyy, position: 0
   Car E -> dealerid: yyy, position: 1

   Due to this special "ordered" index, the position field will always maintain a zero-based ordered value for the given scope. If I modify any member, this ordering is preserved:

   Change Car C position

   Car C -> updateOne(position: 1)

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: **, position: 2 <-- updated
   Car C -> dealer_id: **, position: 1 <-- updated
   Car D -> dealerid: yyy, position: 0
   Car E -> dealerid: yyy, position: 1

   Change Car C dealer_id

   Car C -> updateOne(dealer_id: yyy)

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: ***, position: 1 <-- updated
   Car C -> dealerid: yyy, position: 1 <-- updated
   Car D -> dealerid: yyy, position: 0
   Car E -> dealer_id: yyy, position: 2 <-- updated

   Change Car C position to be a very large value

   Car C -> updateOne(position: 999)

   Car A -> dealerid: ***, position: 0
   Car B -> dealerid: ***, position: 1
   Car C -> dealerid: yyy, position: 2 <-- updated, stays in order
   Car D -> dealerid: yyy, position: 0
   Car E -> dealer_id: yyy, position: 1 <-- updated

   Change Car C position to a non-numeric value

   Car C -> updateOne(position: "foo")

   update is ignored; nothing changes

   This feature should work with partial filter expressions, etc.

   I would like MongoDB to add better support for ordered lists across documents in a collection. This feature would allow the user to designate a field such as "position", and the DB would ensure the values of that field across documents remain in a monotonically-increasing integer sequence 0, 1, 2, 3, ... N.

   I am the maintainer of a Ruby library called "Mongoid Orderable". This library makes numerically ordered field across documents. I'd like to ask MongoDB to investigate moving the functionality of this library to the server.

   What use case would this feature/improvement enable?

   This feature would be useful… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

8. Make it clear an index not on present on all shards

   We recently had an issue where an index did not get created on all shards. When we ran getIndexes() on mongos it reported the index was present. So we dropped another redundant index thinking all would be well - it was not. We had serious performance issues on the shard that was missing the new index and our app was unavailable for a few hours whilst we re-created the missing index on a huge collection.

   It would be better if getIndexes called on mongos reported some sort of warning or indication that it was not present on all shards. The same should also be clear on mongo cloud's index view. Even better would be some guarantees that an index will get distributed to all shards, even if there is a transient problem with one of the shards.

   We recently had an issue where an index did not get created on all shards. When we ran getIndexes() on mongos it reported the index was present. So we dropped another redundant index thinking all would be well - it was not. We had serious performance issues on the shard that was missing the new index and our app was unavailable for a few hours whilst we re-created the missing index on a huge collection.

   It would be better if getIndexes called on mongos reported some sort of warning or indication that it was not present on all shards. The… more

   2 votes

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Indexes  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

9. Clustered Collection TTL on _id should support ObjectId.

   Clustered Collections have the ability to expire on the _id field, this would be really helpful if it could use the timestamp portion of the ObjectId.

   1 vote

   Vote Vote Vote

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

   Vote

   We’ll send you updates on this idea

   0 comments  ·  Indexes  ·  Edit…  ·  Delete…  ·  Admin →
   How important is this to you?

   Not at all You must login first! Important You must login first! Critical You must login first!

   We're glad you're here

   Please sign in to leave feedback

   Signed in as (Sign out)

   Close

   Close

10. Compound clustered index

    Now it is possible to create a clustered index for only one field. Since documents can be arranged in ascending order of multiple fields, I see no reason to disallow a clustered index from being a compound.

    Expected syntax:
    
create_collection('testVCFcoll', clusteredIndex={'key': {'_id': 1}, 'unique': True, 'name': ['#CHROM', 'POS']})


    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Indexes  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

11. Support Two Array Fields in Compound Indexes

    Hi,

    I've come across a lot of use cases where the business logic has demanded unique constraints on 1-2 fields that have been modeled as arrays on documents. The cases that only contain a single array field is already taken care of using unique indexes in MongoDB, however the cases with 2 array fields have required application level constraints since the database only supports a single array field in compound indexes. While multiple arrays in a single index would massively increase the size of the indexes, it would be very helpful if it would still be possible. If there are other limitations that makes it difficult to implement support for N number of array fields, then my request would be to increase the limit from 1 to 2, as this would solve all of the cases that I've encountered (and any reasonable cases that I could think of).

    Thanks in advance,

    Hi,

    I've come across a lot of use cases where the business logic has demanded unique constraints on 1-2 fields that have been modeled as arrays on documents. The cases that only contain a single array field is already taken care of using unique indexes in MongoDB, however the cases with 2 array fields have required application level constraints since the database only supports a single array field in compound indexes. While multiple arrays in a single index would massively increase the size of the indexes, it would be very helpful if it would still be possible. If there are… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Indexes  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

12. Please report mixed-type numeric _id fields in $merge stage error

    Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

    https://jira.mongodb.org/browse/SERVER-61613

    The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

    db.b2.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },
    
      { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }
    
    ] 
    
    db.b3.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },
    
      { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }
    
    ] ```
    
    When I merge each into a collection `pg` with this syntax:
    
    

    db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);
    ```

    , it reports a cryptic message:

    MongoServerError: $merge failed to update the matching document, did you attempt to modify the id or the shard key? :: caused by :: Performing an update on the path 'id' would modify the immutable field '_id '

    The pg collection is just an example that in real life is a an aggregation stage before $merge.

    The underlying issue is that b2._id is BSON int and b3._id is BSON double, which is not visible in Mongo Shell, and that Mongo DB server fails to recognize numeric types that would work just fine in other comparisons, like queries.

    Please report an error or a warning that _id fields in merged collections are of different numeric types, so it would be clear what the problem is, which will save people a lot of time trying to figure out why the type of _id is being changed.

    Given that _id is immutable, people would have to drop the collection and recreate it, which may be quite tricky for large databases. If there was a tool to do that or if the server would recognize compatible numeric values and report the error only when numeric types cannot be coalesced, it would also be helpful.

    Posting this idea at the request of one of the Jira users. You can find more technical details about this in the Jira issue:

    https://jira.mongodb.org/browse/SERVER-61613

    The gist of it is that I may have two collections, b2 and b3, that are not distinguishable in the Mongo Shell, like this:

    db.b2.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T23:16:33.149Z") },
    
      { _id: 2, created: ISODate("2021-11-18T23:16:33.149Z") }
    
    ] 
    
    db.b3.find()
    
    [
    
      { _id: 1, created: ISODate("2021-11-18T22:53:02.113Z") },
    
      { _id: 2, created: ISODate("2021-11-18T22:53:02.113Z") }
    
    ] ```
    
    When I merge each into a collection `pg` with this syntax:
    
    

    db.pg.aggregate([{$merge: {into: "b3", whenMatched: "merge", whenNotMatched: "fail"}} ]);… more

    1 vote

    Vote Vote Vote

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close

    Vote

    We’ll send you updates on this idea

    0 comments  ·  Indexes  ·  Edit…  ·  Delete…  ·  Admin →
    How important is this to you?

    Not at all You must login first! Important You must login first! Critical You must login first!

    We're glad you're here

    Please sign in to leave feedback

    Signed in as (Sign out)

    Close

    Close