I want to know if primary objective is mandatory for activities?
Thank you
No, you don't have to declare a primary objective for each activity. In fact if you don't declare a primary objective, the LMS will create one for you since the LMS uses the primary objective in the rollup and sequencing processes. However, if you create local objectives, you have to declare a primary objective in your manifest file.
Related
New to DynamoDB, I have the partition group_id, and sort key groupid_storeid_sortk.
I am wanting to setup additional access pattern with the group_id and store_addrss_sortk.
Will this have any impact on performance using the partition key in the secondary index, or would it be better to create a new attribute as the secondary key, even though it would be duplicate data.
ThankYou
It’s fine to use the same partition key attribute again as the PK for the GSI. No problem there.
For the future: You may want to watch some videos on single-table design and start using PK/SK as generic names since you might want to overload what’s inside them for different items. And then you might want GSI1PK/GSI1SK as the GSI keys.
That’s a style thing when you aim for some optimizations single-table design can bring.
An index is simply another table that you don't have to manage yourself. When you create an index, the service (DynamoDB, for example) creates a new table for you and manages the synchronization of the data between the tables.
In DynamoDB you have two types of secondary indexes, Global and Local. If you use the same partition key, you can use both of these options. However, you have to define the secondary local index (SLI) when you create the table and you can't add it later. Only secondary global indexes (SGI) can be added after the creation of the table. You can read more about it in DyanmoDB documentation.
Regarding performance, you need to consider the cost (read/write capacity) on top of the usual time considerations. You need to see if you are writing a lot to the table and not only reading a lot. Based on that you can plan carefully the projection of the data into the new index. Remember that writes are about 10 times more expensive and slower than reads. You can read more about projection best practices here.
I'm new to "DynamoDB" and wanting to know best practice to maintaining unique partition key value when you add records to a table.
With my existing experience related to SQL, primary keys are normally maintained by the system with identity columns or via a trigger. I've searched through various forums and "AWS" documentation, but did not find any specifics. Do you manually determine the existence of partition key value or am I missing something obvious?
In DynamoDB the querying is flexibility is limited when compared to SQL. So the schema as well as partition key / sort key should be designed to make the most common and important queries as fast as possible. You can find some generic best practices here
https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/best-practices.html
https://aws.amazon.com/blogs/database/choosing-the-right-dynamodb-partition-key/
If you can provide better context on the use case that you are trying to use DynamoDB, you should get more pointed answere
Moving resources is easy, but will the ARM template, which uses ‘uniqueString(resourceGroup().id)’, still update the moved resources or create new resources?
It will create new resources. From the documentation on uniquestring it creates a deterministic unique hash from the parameters. You're feeding the resourceGroup id to create the hash. If that resource group id changes, so will the hash.
If you're appending a value to create uniqueness - a simple way is to change the template to refer to a variable called suffix, and directly assign the previously created unique id to the suffic variable.
If you wanted to create a portable, reusable template that would allow you to move resources between groups, then you'll need a different value to seed your deterministic hash, and not something that's likely to change. I use subscription().id frequently.
Another thing to look at is the template function documentation which allows you to define your own functions. You can encapsulate the unique naming logic in there also.
Probably not the answer you wanted to here though.
I am trying to form a new table that contains unique user_id's from existing one. Is it possible to add auto_increment primary key in U-SQL like we can add in MySQL?
To elaborate on David's answer: Unlike MySQL, ADLA/U-SQL is executed in a scale-out shared nothing architecture. Thus there is not an easy way to manage auto-incremental numbers.
However, there is are some tricks that you can use:
You can use the ROW_NUMBER() function to generate a number per row. You could add that to the MAX you have so far.
Or you could use DateTime.Now.Ticks to get an initial seed (plus some additional offset if you want to make sure you do not have overlapping ranges between different inserts) and the use ROW_NUMBER().
Less recommended is the use of NewGUID(), since that generates a different guid and is not repeatable. Thus if a vertex is retried, it may fail the job due to non-determinism.
I hope this helps.
This is not currently possible.
I am populating a medium-sized table (60GB, 500 million rows). The process completes reasonably fast if the table has no primary key (~1 hour using bulk insert), but it takes ~10 times longer if I create that table with the primary key. I assume this is because it takes time to verify the uniqueness constraint and also update the index at each insert.
I thought a good workaround would be to add the primary key later, since indexation on the table that's already populated should be much faster compared to incremental indexation. But sqlite doesn't seem to have the option to add primary key after the table is created (not sure why?).
I guess I could just not use a primary key at all, and instead just add a unique index after the table is populated. Is there any disadvantage to that?
Or any better solution recommended?
From a purely technical point of view, an unique index has exactly the same effect as a primary key. (In SQLite, some primary keys allow NULLs for backwards compatibility.)
The only difference is that the primary key constraint does not show up in the table definition itself, which might be a bad thing for documentation purposes.
Also see Is CREATE UNIQUE INDEX or INTEGER PRIMARY KEY more performant in SQLite.
Run the bulk insert inside a transaction and you'll avoid quite a few things that slow inserts down.
I just found this which is a great write up on how to speed things up in sqlite3.
Improve INSERT-per-second performance of SQLite?