Ian Bennett
My feedback
-
2 votesIan Bennett
supported this idea
·
-
35 votes
Have you considered using a lambda architecture in Cosmos DB?
This is a very typical pattern for IOT and Cosmos DB. Feel free to take a look here but I think you can get precisely what you want using Cosmos DB with Change Feed and Spark.
https://docs.microsoft.com/en-us/azure/cosmos-db/lambda-architecture
Thanks.
Ian Bennett
commented
My partition keys are GUIDs in order to evenly distribute eclectic data over the partitions. I therefore do not know the keys upfront and "DISTINCT partitionKey" is of no use.
Ian Bennett
commented
Also, it looks like the node.js SDK does not support passing of partition keys when executing a stored procedure.
Ian Bennett
shared this idea
·
-
72 votes
Hi Ibrahim,
What issue are you trying to solve? What use case would this be used for?
It seems to me that placing a restart option on the plan level might do more harm than good, by resetting the memory on all the apps under the plan. Depending on your scenario, auto-heal would be a great solution to solve individual machine issues. See a video by my colleagues here for more details: https://channel9.msdn.com/Series/Windows-Azure-Web-Sites-Tutorials/Auto-Healing-an-Azure-App-Service
Placing this idea under review for now until I understand what’s at the base of the request here.
Thanks!
OdedIan Bennett
supported this idea
·
Ian Bennett
commented
There are some services that appear to be App Service Plan based and if broken, cannot be resolved by restarting at the App Service level. For example, MSI (Identity) which was apparently a VM plugin (there appears to have been major changes to MSI so not sure if this is still the case). Also I am having problems with Always On across all of my App Services (i.e. it has stopped working) so I suspect this may be another case.
-
4 votesIan Bennett
commented
Agree that there needs to be some way to organise related Logic Apps. I have to use 3 Logic Apps just for overnight scheduling of lights at one site (1 to turn lights on, 1 to dim at a later time, 1 to turn off). If I am to roll this out in ernest I would likely end up with thousands of Logic Apps which will be a nightmare to manage, so am having to look at other solutions.
Ian Bennett
supported this idea
·
-
1 voteIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
2 votesIan Bennett
commented
Sorry, I actually gave up on using MSI.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
6,646 votes
We are looking at options to enable this.
Ian Bennett
supported this idea
·
-
1 voteIan Bennett
shared this idea
·
-
524 votes
Work on Bytecode support has started. Will update here when this becomes generally available.
Thank you for your suggestion and votes.
Ian Bennett
supported this idea
·
-
2 votes
@Ian.
With regards to secondary regions having different RU/s we do not have this on our road map at this time. There is another User Voice items which have this suggestion, Please feel free to vote that item up.
@Nick.
For scenario 1. Same answer.
For scenario 2. Typically, just putting the front-end closer to users is not something we see help with application latency where they are backed by a database as the app still needs to call the database which is still separated by some distance.
With regards to knowing which region to point to I would suggest conducting tests to see which regions provide the best latency and include this as the preferred regions for each regional deployment.
Thank you both for your suggestion and comments.
Ian Bennett
commented
The replica is setup more for DR purposes but there is no option to run the secondary at reduced RUs so that is potentially a lot of wasted resource and money. If I am using something like Power BI Service then I don't get a lot of say in where the application runs from. You are assuming a 3 Tier Architecture but Cosmos is not just being used for apps and websites. Data Analytics applications are often 2 Tier and more taxing on the database.
Ian Bennett
shared this idea
·
-
13 votes
This capability is not on our road map today but we do provide query metrics using our SDK’s. You can read more about what we provide here, https://docs.microsoft.com/azure/cosmos-db/sql-api-sql-query-metrics#query-execution-metrics.
Thank you for your suggestion.
Ian Bennett
commented
By "monitor" I mean individual queries and the focus on this suggestion was actually meant to be on the "killing" part. Its not hard to end up with rogue queries chewing up the RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
11 votesIan Bennett
commented
A trigger based on "Number of requests exceeded capacity" metric would be useful too. Logic flow might look something like if number of requests exceeds capacity > n then increase RU throughput by 10% with a maximum of x RUs.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
commented
Occurs when timestamp is a string but not when a number. Range indexing is used on string by default. Otherwise, performance of range query on timestamp is similar for both number and string formats.
Ian Bennett
supported this idea
·
Ian Bennett
shared this idea
·
-
0 votes
We are investigating this now. Will report back.
Thank you for reporting.
Ian Bennett
shared this idea
·
-
1 voteIan Bennett
shared this idea
·
-
1,144 votes
Thank you for all the feedback for the preview of RU/m. We are currently reviewing feedback to drive further improvements. Please stay tuned. For any questions, please reach out to us at AskCosmosDB@microsoft.com
Ian Bennett
commented
For partitioned collections it would be good if autoscale would work on a per partition basis to keep costs down. RU allocation across every partition can be inefficient as in the following examples.
1. RU allocation applies to all replicas. Using node.js SDK, it is not possible to direct queries to secondary replicas so that RU goes largely unused.
2. In some use cases it can be better for performance to only use 1 or 2 partitions at a time for read/writes but over time data is spread across all partitions. In this case the RU for all partitions not being actively used at the time are largely unused.
Ian Bennett
commented
My suggestions are, in order of preference:
1. Allow setting of a max RU/s limit and auto scale between lowest possible and up to that limit
2. Bring back RU/m.
3. Allow scheduling of RU/s settings from the Portal (I know this can already be done in a convoluted fashion with command line).Ian Bennett
supported this idea
·
In regards to the Lambda Architecture, that is sort of what I have done but more simply and cheaper by just creating a second Cosmos collection with a TTL setting of a few days only. I write to this and the long term collection simultaneously. Using database level RU allocation I can efficiently utilise RU between the short term collection which is mainly queried adhoc during the day and the long term collection which is mainly queried in batch overnight.