I must say as a long time windows developer, .net core on linux is much simpler than on windows. I'm moving everything I have from windows to Linux and the experience, simplicity, speed, stability, etc are much better on linux.
I guess of you're working with gui that's a different story. But for .net websites and background servers, simply use docker on linux and never lool back. And it's much simpler than docker for windows too.
I completely agree. For some reason they're not 100% ssd and that changes everything. That is the main reason I avoid Azure. Last time I tested (about 8 months ago) I got a new windows server instance with 4gb ram and do a windows update. In my laptop takes 20 minutes, aws takes 40 minutes or so, azure takes almost an entire day! Partly this is because MS doesnt keep their images as updated as AWS, but mostly is because HDD instead of SDD as default. Not advocating anything, just my experience.
I find it hard to believe that any decent chipset made in the last decade at least cannot support 32gb of ram. I had a reasonably cheap samsung laptop from 2012 that already did. If apple is not doing it, it's not by the lack of choices in the market.
Of course, but it's a tradeoff. These low power low profile Intel CPUs can support more memory, but only DDR4 which is desktop class RAM with more than double the power requirements in use, and four to ten times the power usage in sleep mode.
The logic board would also have the redesigned and bigger for the new chipset, putting pressure on battery space. You see Microsoft making the same choice as Apple with the new Surface laptop.
Fortunately Intel are launching new mobile chips with support for fast, low power LPDDR3E memory over 16GB this year.
> It's likely but not guaranteed that n+k was created after n.
This is true in mysql if you rollback a transaction, or use a INSERT INTO ... ON DUPLICATE KEY UPDATE.
In the first, the rollback doesn't revert the sequence, in the second the "insert part" will always increase the number, even if there is a duplicate to update.
My point is that nothing stops you from modifying the value of an auto increment column, nor from inserting directly with a specific value. Yes, rollbacks don't roll back consumed values, but an auto increment column isn't immutable and the table isn't required to use the next value.
I've seen an application do things like an INSERT ROLLBACK SELECT LAST_INSERT_ID() to "reserve" IDs... or even perfectly acceptable things like reserving IDs out of a SEQUENCE. Those weren't all MySQL systems, but it did lead to confusion sometimes why gaps might appear or why timestamps might be "inconsistent".
The above one was a potential problem through 5.7 though, as it was possible to reuse some values since MySQL kept the auto increment value in memory only. INSERT followed by a ROLLBACK, then restart the server and you could get reused IDs. It's rare, but I've seen it. However, but it looks like they changed it with 8.0 to save the auto increment value to a system table now. That's a good thing.
I had some real issues with mysql handling more than 2000 connections. Once past that limit, cpu usage increases exponentially with few connections due to context switching. At 3000 connections, 80% of thr cpu was used gor context switching and it got unusable. That was a 64 core/256gb ram server.
I ended up reducing the number of clients. In my case I had a thousand servers, and I was able to change the application structure and merge them into a dozen big application servers. Now with connection pooling each server has less than 100 connections.
As a more permanent solution for scaling, I'm moving out of mysql into something more distributed.
I think it's different. From the docs, this is a one time update to the table. The table itself is not clustered, it's just ordered based on a clustered index, so selects by default should come in that order. But once an insert is done, it's again ouy of order.
Also, an order by using the cluster field most probably invokes an index scan, while a clustered table doesn't.
I use UUIDs in mysql as primary keys in tables with a few million records, and I'm about to migrate a few tables with billions of records from bigint to uuid.
Never saw any real problem. I use char(36), as it's easier to query manually when needed, but I' looking into binary(16) for those billion row tables.
I think most issues with fragmented tables are old problems since ssd, and the overhead is something you will only notice in benchmarks.
If your keys ate supposed to be uuids, the just use them and get the hardware to handle it. In reality, you're most likely to be affected by a zillion other things before an uuid as pk.
> I use char(36), as it's easier to query manually when needed, but I' looking into binary(16) for those billion row tables.
I would use whatever data type your RBDMS's UUID generator returns or the programming language your application is written in. If your RDBMS supports a UUID or GUID data type, however, I would 100% use that because you'll invariably have functions which help you deal with it.
Remember, however, that many (most?) RDBMSs store records in pages (or blocks) of a fixed size typically between 4KB or 8 KB, and they won't allow a record to span a page (usually when a record is too long for one page, non-key data will be moved to non-paged storage which is slower). In other words, if you reduce your record size by 20 bytes you might not actually see as big a change as you'd expect. You'd be storing less data per record, but you're maybe not changing the records per page. You're not increasing the efficiency of your data store at all because of how the data is physically stored. It also means that the answer might be different for each table since each table has a different row size.
Bottom line, however, is that I would favor storing UUIDs the way your particular RDBMS vendor tells you they should be stored. If your application has particular problems with storing UUIDs that way I would look at alternatives, but generally the RDBMS vendors have thought about this a little bit at least.
MySql doesn't have a UUID data type, the UUID() function returns a varchar. The way you store it is mostly preference and driver defaults. The C# driver used to handle binary(16) as Guids, then they deprecated that in favor of CHAR(36). But when dealing with a bilion rows, each byte counts and I'll favor binary(16) because it's smaller and that helps with the index sizes and memory usage.
I don't have the numbers here, but I'm pretty sure the same idea applies for serverless. If you have a predictable load, you can always find a much cheaper alternative once you pass a certain threshold. The cloud is never about cost, it's about flexibility.
Predictable or flat/consistent? If my load is negligible in US weekends and outside of business hours, that's a factor of 2 or 3 you can theoretically save over baseline=peak with some "cloud on demand" service.
It's not an order of magnitude, but it's something. Probably not worth the effort, for most, though, and I have no idea if "dedicated box" services can approximate something similar.
If you have a small number of requests over a large period, serverless is cheaper (that includes an api that is idle most of the time and peaks at a very high rate occasionally).
But once you go live and start to grow, there is a point where the lambda cost equals the instance price. And with an instance, you can almost always do a lot more than that number. Again, that will work if your requests are predictable enough that you can see this number consistently over a large period, say, every week at least.
You're completely right. You can get an amazing server in a very good hosting provider at a fraction of AWS. Really. You can get for $200/month a good server in a good hosting that costs literally $5000/month or more on AWS. Azure and Google are not different.
What you don't get is all their regions, easy scalability with EBS, managed services, etc. But all of that has a very high price, and depending on who you are and what you're trying to do, these cloud providers are probably the worst option.
Imagine you want to create some new machines. Maybe you need four servers: 2 running Ubuntu operating systems and 2 running Centos.
Traditinally, you would get four physical servers together and then manually load an operating system onto each one.
With the advent of cloud technology, you can simply go to Amazon or DigitalOcean or whoever and just "create" these resources by paying for space in their data centers. You get four "virtual servers" instead of physical boxes you have to configure yourself.
Terraform essentially lets you "code" and automate the cloud provisioning. Instead of going to a dashboard and ordering four servers, you run a script that describes all of the servers you need as well as their operating system / networking / etc. needs. This scales very well (once you have a config you can replicate it to whatever quantity you require) and also provides consistency and reliability, as well as documentation, of your infrastructure.
Terraform provisions servers and infrastructure based on yaml config files that you can do things like commit to source control and see a diff of changes to your cloud provider. It's really fun but very tied into each specific service providers' nomenclature and services, I wish it was higher level. It provides backends for all the major players but I think there is (was?) some large variation in quality.
I guess of you're working with gui that's a different story. But for .net websites and background servers, simply use docker on linux and never lool back. And it's much simpler than docker for windows too.