Measurements in F# is an exciting feature. No doubt about it. I was really impressed when I learned about it being added to the language.
It surely addresses a lot of potential issues with measurement mismatch.
Yet, run time support for measurements still makes a lot of sense.
If you are reading data from external sources at run-time (files, sensors, or web services), you'd still have to implemet all the measurement tracking and conversion yourself. If this can be married to contract somehow, then application would just have to
tell the framework that it expects mass to be in kilos, and if input feed turns out to be pounds then conversion would happen under the scene.
Another presumably useful feature would be to declare measures off of classes/types. If for example, I'm counting my chicken, I don't want to be able to inadvertently add this to the count of eggs, unless I explicitly coersed chicken and eggs to be "things".
Anyhow, compile time support is a very good start.
Now, this in-memory columnar database, is it going to be shipped along with Gemini only, or it eventually make it into some edition of SQL Server engine?
Sure, database query language doesn't have to be SQL (or arguably even shouldn't be SQL), but querying language aside, such a compelling feature as in-memory columnar storage looks very appealing as a generic service.
Columnar in-memory database storage, wow, that's some serious stuff!
A question though, when a dozen of users load their BI-mini apps onto the server and try to run them all, will there be 10 copies of in-memory database on the server (which might quite easily kill the server on the spot)? Or the server version of columnar
database in not in-memory?
Good introductiory video. Not too many technical details though.
Are compute node SQL Server instances running the same code as the coordinator? Doesn't sound like they need to.
Is data auto partitioning going to be supported?
How Madison compares to now Oracle's Exadata?
What kind of storage (row oriented, column oriented) is used for compute nodes?
Coordinator still seems like a potential bottleneck, if 150 compute nodes start streaming back to the corrdinator, on a poorly scoped query there is still a good chance to food it with data. Are there any provisions for scaling out the coordinator, or it's
vertical scaling for now?
Really looking forward to more videos on Madison (with a bt more details on internals ) .
Is there anything that can be used in cases when binaries are coming not from the internal dev.team or a major vendor, like Microsoft, and there is no .pdbs immediately available? Is it possible to blindly search for a sequence of machine code instructions
(naive signature matching)? Or in this case /gs injected code "optimized out beyond recognition"?
Good video. It's been quite a while I had to write anything in C/C++, so excuse my ignorance.
But, is there a utility to quickly check if an executable or a DLL contains modules that were compiled with /gs or /gs++ flag? In another words to do some sort of a static analysis of program binaries to have at least some level of confidence that it was
hardened against buffer overflows?
Charles, close to the end Andrew mentioned that SQL team is working on putting more CLR into SQL Server.
Is there a chance to interview anyone on the SQL team on that? Are we to expect T-SQL being (finally) executing on the top of the CLR (after all, what's the point of having two VMs on a database server doing essentially the same type of work)? Are we (finally)
to see a decent programming language that can be used to do rich data processing inside the database server (code near) instead of (frankly utterly outdated and feature deprived) T-SQL? Something like F# with LINQ directly to relational engine (bypassing SQL
all together) would be a blessing (after all a relational engine does not have to be SQL).
Regarding lazy evaluated methods, I guess what you are really asking for is an object pipeline at VM or even OS level that would be thread safe and allowed multiple contributors and consumers to plug into it. It would presumably address quite a few scenarios
of massive and/or parallel data processing. And yes, it would be nice if all the interfaces that can potentially return lots and lots of data were "pipeline"-aware.