Hello, my name is Harishal Javle, I came to Manipal Hospital because I found my platelet count suddenly dropped to dangerously low level. I've been diagnosed with Dengue and we came in and then we were told that we straight need to go into ICU. So I was in the ICU for a day and my platelet count increased from 18,000 to now it is at 44,000. One of the things that I'm truly impressed with, one of the functions at Manipal is the way they manage the patient diet. When the dietation came, discussed with me, I gave very, very specific instructions and to my surprise all the instructions were followed to the tea, including things like I wanted Borumeta in the milk and I've never seen that kind of stuff. And what makes it very interesting and appreciative is it's a very big hospital, there are a lot of patients and a lot of patients have different dietary needs and the fact that this function is able to remember and implement it consistently meal on meal breakfast on breakfast for me it was mind blowing and it is only possible when there is excellence in work, attention to details and a real dedication for the welfare of the patient self. I mean I single handedly dedicate my one day recovery to the dietary team at Manipal Hospital for that excellent work in managing the quality of food, the dietary supplement that they made sure that they gave so that all the ingredients that they gave were all geared to increase the platelet count and I could see that and I think that's the kind of thing that differentiates a regular hospital from a world class hospital. Thank you.


Today I have the pleasure of speaking with Jeff Mount from Real Intelligence. Is that correct Jeff? Yes, Tracy. Thanks. Nice to see you. Well, I have to tell you it's rare in my life I think this may have been one of the the best written news releases. I've ever seen Did you write this yourself Jeff? Or did you hire someone to do this? Combination. Yeah, a little bit that was mine and those Contribute contributions from our PR team.  It says industry leaders such as Blockbuster, Toys R Us, Borders and Pan Am all ignored warnings to pivot then quickly failed to exit. Real intelligence and authority on the dynamic American financial landscape warns against behaviors that will lead Uneducated and under-trained financial advisors into her relevancy as artificial intelligence rises So how about we just start right there? What gives you the know-how put that kind of very powerful news release out to the rest of us? So we are seeing massive industry consolidation We are certainly seeing the rise of artificial intelligence as it relates to trading financial planning And of course we have robo advisors, which have very quickly Risen to compete in terms of assets and new management with even the insurance companies and bank brokerages I don't know that they'll ever take take over the big wire houses But they certainly have done a very impressive job in terms of growth and assets and new management with those smaller accounts I was recently at a group of investors.  They were explaining how 60% of everybody who enters the Day trading loses all their money because they make decisions based on emotions and the benefit of this artificial intelligence It is this true. I mean, you know, I can certainly look at my own portfolio and cease some validity to their argument It could be I mean time will tell I know last year I saw an article about SRI socially responsible investing on a robo based Format versus what advisors have been doing and the Robo's one but again, that was just one year We will see over time how that actually plays out But yes AI definitely is going to be challenging to compete against I think socially responsible investing by our Robo investors would definitely be down around I don't know our 10th episode if we can even get our heads around this so help me understand this I mean, I know you know 10 years ago when we were walking in in as investment bankers And they were telling us how our analysts and was Chinese Paul And we realized that it wasn't to take long before these senior analysts weren't going to have a job because they couldn't fight To hold on to these top brains and and intellectual abilities. You know, I know we We we hunt them we hunt for these these brains Can you tell me though how this artificial intelligence is going to replace our brains our experience But there's no question. It can do math far faster than any of us Is it going to understand the human condition better than us? No, that's where I think Human-centered financial planning is going to be valued by those people who have the most at risk Okay, we don't want to miss out on this. What do we do? I noticed your your website basically says You know, it's it's kind of I'd like to recommend more people check out here. You're linked in for sure I mean, it sounds like you take us, you know Sad depressed middle-class millionaires and help us become what happy middle-class millionaires or what's really the goal here? I'm actually quite curious. I found the marketing quite entertaining quite frankly. Thank you, Tracy So the objective here is to help the middle-class millionaire feel more confident about Matching up their assets versus their liabilities have a clear understanding as to what they can and cannot do and know that there is a human-centric Financial planner who is behind this to make sure that the strategic thought that comes out of the plan can be applied very quickly and very easily Okay, we know how this game works. We hire ourselves and you know investment manager investment advisor for giving get the get the terms Right, I got a lot of emails. We go out for lunch They tell us how they're taking care of us and we both know those aren't the brains making the decisions and you know We sign up with company a we're pretty much committed to all the tools and instruments sold by that company But we're restricted by it. Is this gonna provide us with more options in the future? I think what it's gonna do is number one offer a little bit more certainty as it relates to risk management because our Process of managing risk is less to do with the old institutional way Which of course is to do the risk profile questionnaire and rebalance systematically We don't believe in that at all instead We believe in aging of portfolios and we need to separate the portfolios on a purpose base Purpose basis if you will whether it's college tuition planning whether it's retirement Capitalizing a small business in the future the actual aging of the portfolio will be managed to the distribution date The advisor then has to deliver an experience that is going to deliver three sets of value propositions They'll be valued by the investor and those value propositions look and sound an awful lot like what you would expect from a family office Client service model which of course is generally reserved for very very wealthy people But we generally bring that to people who are in that middle-class millionaire time frame So those three value propositions or preservation of wealth in multiple ways Obviously we have an eye on investment risk But also managing taxes and managing the possibility of frivolous and fraudulent lawsuits Secondly restore their time to focus and family in their profession and last but not least a high degree of privacy and discretion Well, I don't want to offend you here, but you know frankly you look like a middle-class millionaire How are you finding out and breaking in creaking this door open into these? Multigenerational wealthy family secrets that the rest of us would like to know about I I noticed Your your company says you're gonna provide us with growth maintenance and exit And I know there's many people many of my peers that love all three of those terms and depending on where we are You know our enthusiasm So that the growth maintain and exit really is aimed at the advisor not the actual investor different message for a different group of people but as far as the family office format goes I happen to live in Fairfield County, Connecticut Which is a very very wealthy suburb of New York City surrounded by traditional family offices I'm heavily exposed to what the actual experience is like and Quite frankly we're at an age now where even the things that used to be Unaccessible for the middle-class millionaire really are becoming accessible like private equity investing through mutual funds and ETFs Just putting together the model requires some legwork from the advisor Okay, well, I'm just imagining you you right now sitting in Connecticut with your martini eavesdropping to the guy sitting next to you and taking notes Almost the the Robin Hood for the the middle-class millionaires Anyways, we would love to have you back again. Thank you so much for joining us today I'm absolutely certain our audience will enjoy this. Thank you, Tracy


Hello everyone, I'm the development engineer Shi Hai-Kong from 2.0.com and I want to show you how we operate the biggest retext classes in the world. Next, I'm going to introduce from what I'm first, why we choose retext. Second, how we operate retext in JD.com and my colleague Shi Jin-Ko is going to introduce all the plans we use in our future plan. First, why we choose retext? First, what is retext? Retext is a database clustering system for horizontal scaling of my SQL. So what is working on is working on dividing the database, but not just dividing database. This is the structural map of retext. And we can see the application is application nodes. It could be several nodes. And through the MyCircle protocol to connect to other nodes. And the application is going to send a query to the gateways. And gateways are going to dispatch to the other DNS. And there are also key nodes using the ID as the... And originally the table was used in a different way. And now we can divide these keys, utilizing the ID protocols and putting them into three databases. And in this way we're able to divide the database in different parts. And including the circle and also the tablet, we can connect the shot. And in this database there are three shots. And in the original key tablets, we can put it into three nodes. And we're also achieving the division of the original database. And also there is a typology services as well, including all those... All the tables are going to divide it based on different fields. And all of these will be recorded into typology. And also we have other tools for operation. There were VDC TL and also VT-CTLD. It's providing the external functions originally. For example, I have originally some shots already. I want to add some extra shots. However, I want to change for the other nodes. For example, I want to download or upload nodes. Then in this way I can use the VT-CTLD to operate it. So this is the major structure of VT-CTLD. It's mainly for the dividing of the database. But it's the own dividing of this database. And we have several concerns for... It's because we have several factors to consider when we choose the matrix. There were several characteristics versus my circle. It's well put inside JD.com. And also we have a lot of experience in operating my circle. So that's why we choose these database operations methods. And we will be very competent in this fundamental layer of it. Because inside JD.com there are a lot of other services using my circle database. And now we want to migrate it. We are using my circle. And it just needs a little bit of modification. So the cost of migration is very low. It means I have a lot of data in some database. It may be more than billions. But now I want to put this data on a big data platform to do some analysis or downstream operations. Usually if we have just a very small amount of data we will just use it as that. And then use some of the nodes on our gateways. And then this will be shown on our big data platforms. However when we have a lot of data. For example it's more than billions. Then I will put all this data into the nodes. Gateways. And this will cause some problem within it. With this big amount of data I will just read a lot of it to the gateways and put it on the platform. And then later I'm going to write it on the big data platform. It's not utilizing the streaming operations. And of course the streaming operations means the whole train should be floating and there should not be any blockage at any of these nodes. So all of these nodes should be able to manage these kind of stream operations. And next is the sharing and two face commit. And also the secondary index. And for the next three parts I'm going to talk about it in details. Resharing is doing the data segregation. For example originally we have two shards but there are too many data so I need to divide it into four shards. So we are able to use resharing to do that. And next is the two face commit. And it can ensure it's atomic commits and also to avoid any of the replications during the commits. This is also one of the highlights of the WinTech functions. First is resharing. And we have separated several steps for resharing. First it's copying the data. We can take it as one shard. And within one shard there are the master and also the replicat. You can see the structure here. I want to take one of the replicat from the connection. So this connection has been disconnected. So there is no relation between these two. So this is a drain tier. It's a snapshot data. Originally we have table and we use the id to divide it. And I want to take very simple rules on the sharding, on the segregation. So I want to disassemble them based on id rules and also utilizing the stream query to check it and then put it into this shard. With this id I will put in this shard. Without it I will put in the replicat. So in this way we can deal with the screenshot data. And during the copying process the master data is always writing in. It means that there is some of the delay between the master and the replicat. So I want to replace this replicat because there is some delay of the data. It's going to synchronize some of the bin locks. And Winters are able to synchronize these bin locks and then to analyze it and convert it into a circle. And all of this writing and updating will be synchronized to the shards that we have decided to. And it will relate to the operations of the whole clusters. So without this master and replicat relationship the two parts should be synchronized. It will have some problems. So what should we do? And then the original shards should stop service and we are going to use two new shards to work on it. And originally it's routing to these shards and now it's routing to the other two shards. It just needs to use several seconds. So the resharding just affecting the whole clusters by just a few seconds. This is the sharding system. We have been working on this resharding process for many times already inside JD.com. And here is another Adavitas transactions. We have two things to commit. And I will first focus on multi-shards and there is one question that is debated from the multi-shards. It's too simple, it's a little scary. It's also using the ID for the sharding. If it's less than 512, if it's less than 512, I'm going to put it into shards 0 and for those that are not, I will put it into shard 1. And also I will have another terminal and I will provide a quick verification. So for those ID less than 512, I will put it into shard 0. If it's 900, it means it's larger than 512, so I will put it into shard 1. If it's 400, I will put it, because it's less than 512, and at last I'm going to do the commit operations. And shard 1 has been succeeded in commit. However, the shard 0 maybe have some failure lower and also have some weird or abnormality. And when the shard 1 doing some commit, it means that it will be unsuccessful. It will cause some hold the rollback. So we will see some of the problems from the, it's because of the terminal, the client's terminal that makes this failure. And shard 1 is successful, but shard 0 is failure. So however, overall it has caused a failure of the commit. But you still need to see the scenario of this. If you cannot accept partly commit, then there were two results you can adapt. First, a single shard. All of the data can only be included into one shard. You can put it in shard 1 or shard 0. If this has some failure, then it will tell the clients and also to record the error. And second is to face commit. The second way to solve this problem is to face commit. It means all of these operations will first recorded on the locks, on the cloud blocks. And then before it is submitted, the machine have some problem and we need to wait for the reboot or the recovery. Then it's going to get into the re-block face and it's going to implement this result. And later we will find that data has been committed. So the three re-blocks are going to report this error again. So this is the framework to use by DTX. We also want to meet the scenario. First, if TBS is very high, this is an example. And also we use the KAS. But there is some problem with it. The KAS think it has some problems. And Kubernetes will reboot these nodes and always reboot again. And because it's TBS, it's very high. So that will cause the partly commit problems. But it will be soft-fired to face commit. Of course, the Kubernetes we should deal with the bugs on the KAS. And the second of the index. So what is the function of this index? On VT gates, they will use the VT table as its routing. If ID from 1, 2, 10 put in shot to 0 and for the other part put in shot 1 and for shot 2. And we're going to make it for another part of the name ID. So ID is 1 and 5. And they tell I insert and the ID is 11. And the name is Lisa. The two names are both Lisa, but it has been put in two shots. However, when I do the inquiry based on the ID, for example, then it's going to say the ID is 5. Then it's going to route it to shot 0. Because I use ID for shouting. And then it's going to route me to the shot 0. Sometimes I cannot provide this ID. For example, I can only use name to do the query. Then if the name is Lisa, if we use the name for routing, then what should we do? On all of these four shots, we are going to inquiry all of these four shots once. Although it did not find it on shot 2 and shot 3. And we still need to check it. So this enlarges the reading. So how do fators cope with it to avoid the enlargement upon insertion the ID equals 5? I also saved the correspondence relationship between Lisa and 5. So when Lisa equals 1, then I can check the result very quickly. So I'll search it in this table first, where Lisa is 1. So we have the ID 5 and ID 11. And I only need to search further in shot 0 or shot 1. So I don't need to check all four shots. So I have to avoid unnecessary reading and access. If there are four shots or even 200 shots, then there will be very significant latency observed. Second, I like to talk about how we run fators in JD. This is our internal architecture. So through MySQL protocols, it's connected with our VT gate. And VT gate through TRPC to connect with our shots. The VT shots encompasses the VT shot and VT tablet, two components. And the feedback queries, we feed back eventually to the apps and VT gate through the watch. My mechanism, we're using ETCD to enable the original data storage. And VT data have a watch mechanism which will real-time watch the root information and other changes in original data so that the data can be synchronized with our shots to enable a more efficient synchronizing. And many JD businesses have internal memory requirements based on our MySQL cooperation for two TV business, for example. For some scenarios, we need to real-time synchronize the data on our big data platform by extracting the BING lock to synchronize it with the big data platform. In JD, we have a BING lock service. We'll real-time synchronize the data through BING lake. And the BING lake will offer subscription services for the users so as to enable real-time synchronization of data. In JD, there are four key systems. One of them is still under development, which is a backup system. Real-time backup is still under development. The third one is already being applied online on a massive scale. And I will focus on the three services. First one is JTransfer. What does it mean? So many of our previous services we use MySQL directly and now. The VATES is online, so we are switching to VATES to transfer some of our services. So we real-time extract and synchronize the BING lake data. It is only limited to this stage to enable real-time synchronize. And there is no master replica latency. It is similar to what I have described. So this business module used to visit MySQL module. Now it only needs to visit the new module. They only need to restart the services. It used to connect with MySQL cluster, now switching to VATES cluster. So this is what we do for Transfer. It is mainly used for the key accounts of big businesses in JD where there used to be many nodes, many data. So in this way, we don't have to consider the storage space. In the past, maybe there are 32 charts and we have to expand the key space by ourselves. It is very difficult and time-consuming. Now we are using VATES key space. There are no problems for storage at all. So this is what we use internally. It is also a part of VATES component. It is called an orchestrator. It is an open source to have. We call it ONSC. So on the left side is the ORSC cluster. On the right side is VATES cluster. The orchestrator cluster will regularly, like every 10 seconds, retrieve the data from all nodes, MySQL nodes. There are master replicas, data, latency. And after the retrieving, this data will be moved to the internal storage. And after returning, it will conduct analysis just to tell whether there are some problems between the master replica latency. If there is some problem with the master replica system, then it will select a system with the least latency to switch it. And also, if this master replica is dead, then it will trigger a switching to another master. So no manual intervention is required in the process. Another component used internally is our MOLE. So for our business launching, there are two steps. The first step is the request. So during request, the data warehouse resources will be allocated, for example, how much CPU, how much internal memory. So that's normally what we do. So after the request, the project manager will approve on the request. And after the approval, based on JD's resources, there will be a DBA approval. And after that, there will be an online database will be created. The way we create the table is similar, including the request table, approval table, and DBA approval based on their own professional knowledge to evaluate whether the table's creation has some risk factors, whether it's compliant with the regulations. And after that, the online table will be created. And after the creation, there will be some more interfaces in KBS to apply for resources, scheduling, etc. So the process by creating the table is not too difficult. It's just a database creation. But to change the structure of the table is not that easy. For our R&D people, they have some knowledge of database, but their understanding is somewhat different from ours. We know that for some business requests, there are no primary keys. This is what we are not recommending. Or maybe the primary key is not auto-included. We would recommend the auto-inc function. Or maybe there are some deprecated storage engine or deprecated characters. Or maybe he has created a table and created another one. But the table actually already exists and there's some data in the table as well. So now they are using a dump sequence to delete it. But this is a risky behavior. And there are some even lower mistakes like a syntax error. These are common problems and unavoidable. Next, some of the users, they don't use VATIS. And based on VATIS, we can do some interesting things just like I mentioned by creating the table. There might be some issues, for example, a syntax error. VATIS has one advantage. There's a very good modular based system with very low coupling level. So we don't need to change the modules, even if there are some syntax errors in some modules but because of the low coupling level. For example, I can introduce the tabular module to create a tabular. If there's some syntax error, then I can tell the business department that there's a syntax error in the SQL. So there's no need for PM and TBA approval to identify the error and eventually resubmitting the request. And some of the tables, primary keys and other restraints, like if there's no syntax error in a SQL after analysis, then I can acquire the name of the table, the least information, the primary key information. All this information can be acquired. By then, similarly, I can execute it online a short table sequence. And then I'll look like whether there's a table online. If yes, then I'll tell R&D that your table already exists. No need to submit again or submit the SQL again. Or if the table does not exist, then following these rules, I can examine it and verify these master replica information or whether these SQLs are compliant. It's very easy to deliver these functions. Next, I'd like to, you know, for people interested in beta tests or potential users of beta tests, some advices. My first advice is based on the example I mentioned, the reusing of a beta code. Even if we don't use beta services, we can still use beta code for some of our in-house development. For example, the puzzle module. Actually, in China, there are many teams are doing that using the puzzle module of beta tests. Besides, while doing resharding, they will first extract that bing lock and translate it into MySQL. So all these related modules can be easily accessed and utilized. And also some of the existing MySQL modules, they are not coupling with the business logic of beta tests. And second, let's beta run at the lowest R&D cost because it's based on Valarities. And it's a database and cloud solution. One friend of mine, he's using betas and he tried to run it in an official way. But some of the big teams have a QBS experience and data center establishment experience. But some smaller teams, they have never used a QBS. So let's take that as step. Betas can run QBS, but the first step should be on some of our existing Docker or physical servers to run beta tests first. This is easy to do. And after that, we can provide online production services. And the next step would be further development, integrity development. Especially for OEM, the code may have some bugs. And the operation maintenance may be mishandled. But don't let a problem affect all your services. Especially if the service is big, like hundreds of businesses sharing the same module. Then if one procedure is mishandled and it affects all the modules, it will be disastrous. Now, my fourth advice is to split large clusters into multiple small clusters. Now, JD is using the largest beta cluster in the world. If you are taking the lead, you will encounter problems that no one else has encountered. If you don't want to invest in R&D to solve the problems, split your large clusters into multiple smaller ones to avoid unexpected issues. Later on, my colleague Mr. Jinka will share problems and solutions. Good morning. Mr. Haihua has shared the first and second part and the third and fourth part because of the time restraint, I will quickly go through them. I will talk about some of the problems and solutions JD has encountered and adopted. And next, I will share our future plans. I will start with challenges encountered. JD is operating, fair to say, the largest or the largest in China, VTES cluster. Probably online, we have over 20,000 EPS and around 3,000 EPS. And we have the largest VTK cluster around 400. So in operation, running, we have encountered many problems. So first of all, it's the various demands. And some will say that we have a lot of things that are not supporting. And after we find out these problems, we are going to manage all of these demands. And also the influence between different apps because it's the shared cluster, so they want to have some priorities in this cluster. So during our operations, we also expected that there will be some problem happen in our topology services. For example, the metadata is too big. Sometimes it will have some OAM. So when we commit to the gateway because we have a lot of users, so how can we upgrade these VT gates, et cetera, it's all challenges for us. First of all, I'm going to tell you how we solve these problems. It started from the very demand because it's based on the VTX 2.0 version. And we also have some custom modifications on JD and define some of the look and prepare protocols and also have support some of the more complex, complicated operations. And we found the bugs on VTX. There were some of the leakage in it. Later, we are going to provide the PR to the officially. And next is about the big family. We are going to link the EDCD to Reddix. And as for the upgrade of the VT gate, we are going to utilize its characteristics to do some of the unawared upgrades on the client side. Because we have provided different kinds of accounts like RWR or RS, so some of them can read directly from the warehouse so it can separate the readings. So that it will avoid some of the problems happened to the gateways. And also we will provide specific VT gates to some of the big amount, big demand nodes in the clusters. We also have very detailed monitoring. And we also want to do some more convenient operations on reshutting and do the scheduling more intelligently and migrate from 2.0 to 3.0 because originally working on 2.0 and 3.0 able to satisfy more demands. Just now, we have talked about monitoring everything. So we want to include the VT gate both tablets in my circle, etc. so that we can provide better detailed and accurate demonstration, etc. to the users. And for the original UI and for the DBA, we need to simplify some of the operations. As for intelligence scheduling, it's very interesting for us because we're using some of the machine learning algorithms to include some of the resources needed by the users, including some CPU to do some scalability work so that it can save some of the costs of our company. And later, we're going to migrate from 2.0 to 3.0. So this is the work we need to do. Today, we are very honored to come to share with you together with my colleague. And during the utilization of VTECs in JD.com, we have a lot of help from our team and also from our friends as well. And I also want to thank the VTEC team. Thank you for all your support. Next, we're going to hear more speeches from the VTEC team and their time. And they are on SE16, on the booth at SE16. And you can meet with us there.


Thank you for the introduction, allowing clear, yeah, I think my placement here. So in addition to what he gave as an introduction, I am also a Prometheus team member and I maintained the Prometheus TSTB upstream. So that is why I am speaking about it here. Before we go into the TSTB, what is Prometheus? Prometheus is a metric based monitoring and alerting stack, you can instrument your application or run exporters which will expose the metrics that you want to monitor and Prometheus scrape collect those metrics for you, store it inside, let you alert based on condition. So it is a whole monitoring stack and talking about the time series itself, it has an identifier in Prometheus it is such a set of label names and label values like a pair of strings you can say a slice of pair of strings. The HTTP request total here is an example where the metric is tracking the total number of HTTP requests done for this particular job and that is that one is a special label name which has a custom label name and that is just a value. Along with an identifier time series is just a stream of samples. Here a sample is a tuple of timestamp and a value. We use Unix timestamp and the value can be a float and that is the basis of a time series which we are going to store in the TSTB right now. So Prometheus is huge it does a lot of things but we are only going to focus on the time series database which is inside Prometheus in the middle, how it stores the data in its raw form and just makes it available for queries. So we are not going to worry about anything else that Prometheus does. So here there is a TSTB and the sample that we are going to talk is the timestamp is a 64 bit integer which in Prometheus we store the milliseconds as integers because we found that is kind of enough for most of the use cases and in case of value it is a float 64 value. So Prometheus right now supports more than float 64 custom data structure to store high resolution histograms but for the sake of this talk we are only going to talk about sample having 64 bit integer and a 64 bit float value. So let us before diving into how it stores inside a TSTB it is we can look at the overview. So there is a component called head block it is component which stores the index of the recent data in the memory and recent data in the memory and some things memory map we will see how it works in a moment. So this is the component that first gets the data in the TSTB and after the head has stored data for some time we create persistent blocks immutable blocks which you can show for some term and do queries on it. So we are going to go inside this book itself and how they are created. So let us first look at writing a sample inside the head block. So here is the head block there is nothing inside right now and we get one sample and we create an index entry for this particular set of labels called a time series. Chunk is a compressed set of samples we call it a chunk in Prometheus we use something called Gorilla compression by Facebook and every time you get a sample you compress it in flight and store it there instead of storing the raw samples. But before we put sample into the TSTB we have first created the series entry in the index and then we write into something called write head log we will see why it is required right now. Once we write it into the write head log like log that this write has come to the TSTB we then write it inside the TSTB in a compressed fashion. And inside the write head log if it is the first sample we store the labels of a series and series gets an ID that is ID 1 and we write another record which says the sample is T1 comma V1 for ID 1 it is the write head log it just logs every write that comes to the TSTB. So we need write head log for durability just imagine you did a write request to the TSTB and the system kind of crashed right now or you said to the upper layer that ok this write was successful but if the systems currently crashes all the data is in the memory how you produce it back. So we write a head log to replay the events that happened as is in the writes and recreate the in memory data structure that we had before the crash or even during restart. And we get another sample we write it to the write head log and then the chunk and inside the write head log now you see we do not write a series record because we have already written a series record and you pass through it from start to end. So we just say for ID 1 we got another sample that is about the first step of adding samples in the Prometheus. So let us say you added more samples and it got full right now like you have to cut the chunk somewhere you cannot just keep on growing the chunk. What we do here is once a chunk is full in our case we take it as 120 samples but we are currently trying to cap it at a certain size as well. We just memory map it into something called head chunks.  So you are not storing the compressed chunk in the memory you just you are just holding a 8 byte reference and whenever you want to fetch this series we just take the reference fetch it from the disk and then query on it. This way it saves memory for during majority of the time when you do not need to query that data. And the same process repeats you get more data more chunk gets filled ok now you have a lot of data in Prometheus how do you take care of it. Now we create something called persistent blocks out of the data that is present in the head block right now. We need to do that to make queries and a lot of things efficient. So this process is called head compaction where we take the data from the memory map chunks which are on the disk and also some data in the memory if it falls within some logic that Prometheus decides ok we want to compact data from this time range to this time range and just create a block. And the same process repeats we create another block the earliest block I am numbering it n the new block is n plus 1 it is like a linear set of blocks that come into the TSTV ok. But why do we need compaction? So time series are not always the same after some time you may be ingesting data into new set of time series. So you do not want to hold index record of that in your memory. So once you compact and put the flushed data onto the disk you use those index entries from the end free space also you are holding the chunk references in the memory that also gets cleaned up and restarts will also be faster because now you have to replay less set of events to create the memory structure ok. So what about the bigger block if you notice in the diagram I have the n minus 2 block as something large block it is we created from the smaller blocks that we just created. So imagine you have 4 blocks A, B, C and D. So based on some logic we choose 3 blocks at a time and just merge them to create a bigger block we will see why it is required soon like every block has its own index and we are going to look into the index soon. Yeah block compaction is for efficient queries it also reduces the disk space usage because the index is not repeated and we will see soon how. So before we look at the block at some point you want to get rid of the old data you do not want to store the data in your system because sometimes you do not need the old time series data. So you can configure TSTB to have retention based on the disk space usage and also how much time range your data is covering. So this is an example of time based retention if we consider this as some kind of number line every data which is beyond the red line we have to delete it. But if a block overlaps we cannot pass immutable we have to delete a whole block together. So once we add more data and create more blocks and the block goes outside the retention range it is just simply deleted like there is no waiting as soon as new blocks come up the old blocks goes outside the retention range the data block is just removed from the system. So this is at a high level how TSTB works lets dive a little deeper into a block. So inside the persistent block which is created out of a head block it contains an index which maps all the data that is present in the block it has a meta telling all the important information about the block which will let you decide how to and when to query it. Tombstones for deletion will come to it soon why we need tombstones and why cannot we delete the data from block immediately and there is the chunks themselves. So we store all the chunks together in a bunch of files all the compressed samples chunks are compressed unit of samples. So let us look at all of them one by one starting with the meta file in the meta file like every block has a identifier which is called universal identifier and block stores data from a particular min time to particular max time. So if you look at the meta you know what is the time range this block is covering few health information like how many series how many chunks and if the block was created from other blocks we also store the parent blocks for debugging purposes. Now let us look at the chunk files themselves this is pretty simple it has a list of files every file is capped at 512 MB and in every file we just store the compressed chunks as is because all of this reference is mapped inside the index and the reference is stored in a very simple manner. So we have a 8 byte reference for every chunk the first 4 bytes stores the file number in which the chunk exists and the last 4 byte stores the byte offset in the particular file where the chunk exists. So if you if I give you a 8 byte reference with the first 4 bytes you will which you want and you will take this last 4 bytes and just seek your file to that byte offset and there you have the chunk the chunk has helpful meta information to know how much to read at time. So this is a simple way how chunks are stored on the disk the most interesting part is the index Prometheus stores index in something called an inverted index format and see we will see how it stored and how it square it both. So at a high level the index has 4 components first is the symbol table the symbol table stores all the symbols basically the strings that were seen in a time series. So the symbols are like if you had label name HTTP request total that is a symbol job equals to nginx then job is a symbol nginx is a symbol. So all the symbols are stored together in a single table because if you repeat all the symbols in the index everywhere it just takes a lot of space. So you just store it in a label in a sorted fashion and just use index the first symbol is number 1 the second symbol is number 2 and just use those numbers everywhere in the index so whenever you have to get the actual symbol you look up this table. So this is the purpose of symbol table and now the series itself. So it stores the labels that pertain to this particular series instead of storing the string itself it uses the symbol table index right now to store which labels are for this particular series and then a slice of chunk references. We saw earlier that chunk reference is just a 8 byte number but with every chunk we store what is the min time of the chunk what is the max time of the chunk and what is the encoding of the chunk so that we know how to decode the chunk. And the series are stored in a sorted fashion based on their label values like or first based on the first label name and value then the second label name and value and so on. So if you take s1 and s3 we know that if we sort it again s3 is going to come after s2 and s1. So this is how series is stored these are just simple plain information that is stored in the index. Now we come to the interesting part so in inverted index word the postings are nothing but the series I skipped one part here. So every series has a reference s1, s2, s3 that I am mentioning here. So those are again byte offset in the index. So if I give you a series reference called s1 you just take an offset in the file with s1 and there you get the series. In Prometheus we align it to 16 bytes so reference is actual byte offset divided by 16 and if I give you a reference you just multiply it by 16 and get the byte offset and you directly go to the series where it exists. And postings are nothing but those series IDs. So postings are series IDs and we store a list of posting lists. We will come to it in a second why we are storing a list but this particular section stores a list of those series IDs and the reference Pl1 Pl2 is again the byte offset in the file. I will come back to this again after looking at the next stuff. So there is posting offset table this is the important part. So you saw every series has a set of label name and label value pair and when in this posting offset table we store like okay foo1 equals to bar1 is present in a set of series which is represented by the posting list one and foo1 equals to bar2 is present in this particular set of series. So this is how we store the inverted index for every label value label name and label value pair we store what are the set of series that correspond to this. So this just points to a posting list as a reference and based on Pl1 Pl2 Pl3 we can look at this table to actual set of series that are for this label name and label value. So now we will see how we use the index to query. So let us say now I want to query in Prometheus fashion this should fetch series that has both the labels foo1 equals to bar1 foo2 equals to bar3. So we take one matcher at a time let us see we take the we look at foo1 equals to bar1 and foo1 equals to bar2 against the posting offset table okay now we know it matches a particular set of posting list. Now we have the reference where the posting list exists. Now we take the reference look at the posting table and we get the set of series references that actually match these label values and now that we have two sets of series like series references you just intersect them and finally you now you know that this series mentioned by the reference s6 and s22 matches the query that you get. This is a simple query that you can do on TSTP and now you have s6 and s22 you just take those references again and look at the series table and now you get the series and the series now tells you what are the chunk references that you have and then you can just fetch the chunks and do the query on that and depending on the time range that you have queried let us say you have queried from T1 to T2 you just trim the chunks when giving back to the API caller. I will go back to this diagram again so in short we started at posting of when querying we started at posting offset table with that information went to the postings from there we went to the series and we finally got the data. So when you have to this is about querying a single block like the index is concentrated on a single block when you have to query multiple blocks you do individual queries to each block even the head block gives the same interface of using the label name and label values and get the samples and series pertaining to it. So there is a there is just an implementation called courier which queries each individual blocks and then merges the data together. So this is where the big block comes into help if you have less blocks big blocks look up less number of blocks to get the same data and because the index series because sometimes series stay for a long period you again de-duplicate these entries. So that is the use of having a bigger block and it is not just the equal matcher that used to be gives you can also do not equals to or you can match a reg X or you can say if it does not match a reg X just give me these results. So finally we come to the tombstones. Tombstones are there to record the deletions that you make on a block because the blocks are immutable if you have to delete a data and series you have to recalculate the entire index because all the offset and everything is calculated based on the byte offset. So that is very inefficient. So when you get a deletion request you see which series it affects and what is the time range the deletion is asked for and you just record it in a file called tombstones which just says for the series reference this time range is deleted and so on. This is usually small so we do not really optimize stuff here and whenever you are querying when you are looking at the chunks you also cross verify with tombstones and only return the data that does not overlap with these tombstones. So we have like 6 minutes so I will quickly cover a couple more things. We talked about head chunks that we maintain in the in memory database part. We have to see how we replay it on startup and there is another artifact called a snapshot on shutdown which kind of helps in this replay we will see in a moment. So when we are replaying the data you first replay all the head chunks basically the compressed chunks that you have on the disk and once you have that you replay the right head log like in when you are replaying the right head log decompressing the right log takes roughly half of the time and then actually ingesting into the TSTB takes roughly half of the time. The help of the memory map head chunks we can discard samples which already exist in the compressed chunks so that saves quite a bit of time but still replaying a right head log is a little slow. So there comes a snapshots on shutdown where everything that is that you have to replay on a startup when you are shutting down gracefully you just take a snapshot of that you take snapshot of all the series that exists instead of taking it from the right head log records and then take the snapshot of the in memory chunk which has not been flushed to the disk in which case you do not have to go to the right head log. You can simply skip the right head log just replay the head chunks and snapshot this way you can speed up the replay and there are another component called right behind log which is used for out of order ingestion of samples. The process that I showed right now every sample has to have a timestamp greater than the previous sample for the particular time series for the compression to work well. So there is for out of order ingestion we have another artifact but because of time crunch we are also not discussing that and this was a very brief introduction in 25 minutes you can only explain so much. So I have a 7 part block post which explains everything in detail. So if you want to link two slides you can scan the first one if you want the link to the block post you can scan the second one. Thank you. So we have 4 minutes for Q and A. Do we have questions for him? Wow that was a very well received. No but I was quite intrigued I have never seen actually TSTB structure before head logs which is a very common idea right? I would like to add one more thing like this TSTB block is not just used by Prometheus there are projects like Thanos, Cortex and Memer which are distributed time series database built as an extension to Prometheus for long term storage. They use this specific block format to store their data like they literally use the TSTB code its open source its go code they literally create the same kind of blocks and they have some kind of superpower in the sense that the blocks are distributed in Prometheus it is all on a single machine and Memer Cortex Thanos it is distributed so you can the when querying multiple blocks you can just run a query on a separate machine and that way you can speed up the queries. So this TSTB block format is used by multiple popular distributed database as well.


Welcome to Sheboygan County government working for you. In fact, welcome to our 100th program of Sheboygan County government working for you. Pleased to have you with us today and also pleased to have Mike Tabenheim, our administrator of Rocky Knoll. It's been a year since he's taken the reins over there and Chairman Mike Van der Steen and I are looking forward to discussing with him what's all happened the last year.  Sure. First of all, thanks for inviting me and it's a real pleasure to find out that it's the 100th show, so I get to hit the centennial. I've been in the healthcare industry some 35 years now. When I started out, I joked routinely that I would never live to be 30, much less, you know, be in the business 35 years. So it's been an interesting experience so far. And you're back to your roots here in Sheboygan County. I am, I'm originally from Sheboygan. I was born and raised, went to urban and north high and then off on a wild tour of the United States. Well, it's good to have you back and good to have you on your program. In fact, 100th program, we thought we really had to bring on one of our most successful department heads and it was a tough discussion, Mike and I went through because we've got a number of good folks but you made the cut. Well, thank you, I'm honored. I'm honored, I'll collect the plaque later. Later, off the year. Okay. Mike, tell us a little bit about some of the greatest challenges you had coming to Rocking Hill right out of the gate. I know you had to take on some big challenges. Yeah, I did. It's been an exciting year but there have been some significant challenges. Probably one of the biggest was I came on board right on the heels of the transition as Sunny Ridge was privatized and a lot of the staff from Sunny Ridge as with County Comp Pryor were now at Rocking Hole. So basically, I would say that was probably one of the largest challenges that I had was to create a new team out of these three separate workforces and I remember a lot of staff introducing themselves, hi, I'm Jim, I'm from Sunny Ridge or hi, I'm Bill, I'm from County Comp kind of thing and trying to remind everybody there from Rocking Hole. So it's taken quite a bit to get the staff to acclimate and join as one and focus on their new home or home now as Rocking Hole. So that was probably one of the biggest, the other was a concern as to what would happen to Rocking Hole. Would it be privatized? Would it be closed, sold? What would happen to it? And so as we worked with the staff, getting to know the staff, that was probably the second big issue that I'd noticed and had to work with. And then of course just getting your hands around the operation itself, what we were doing, how we were doing it, what was working, what wasn't working and figuring out where to go. So a year ago, August, you walk into this building with staff from essentially three facilities, Rocking Hole, Sunny Ridge, Comprehensive, all have come together, we just went through the difficult bumping process associated with privatizing Sunny Ridge. What were your impressions? What were your first impressions of the facility and of the staff? The facility, first of all, was a gorgeous facility. I mean it's a very big campus and that's probably the best way to phrase it, comprised of three distinct buildings. Original building of the current configuration was built in 1972, another in 1992 and then the latest addition, our Woodlands unit short-term rehab in 2002. So it was a good building out in the country. So from a location, location, location kind of thing, you had the location in terms of the beautiful scenery, the secluded environment, but you were away from most of the activity. We're probably one of the furthest facilities away from any of the area hospitals, which are your main feeder sources and that. So while it had its pluses, there were some minuses that you would have to deal with and overcome. The staff was just impressed, just blown away by the seniority, by the experience level of the staff there and while there was a lot of challenges trying to get them to grow to be a single family, you certainly had the wealth of experience and skill to work from. Probably by far the most seniority and experience that I've ever had in one building in my 35-year career. And when you're talking about quality of care, of course some more senior experience staff, that's gonna bode well for the residents they care for. How about your management team? Of course you've been working very closely with them, what was your impression there? Equally as impressed, very devoted individuals, with again a lot of seniority, some of these department heads have been in the county system for over 25, 30 years and very impressive skill levels.  But they brought all the basic sound foundation tools that you would need to move forward. Very dedicated and very interested in being successful and making Rocky Hill successful. Well as you know, the county board struggled for years with the size and scope of healthcare centers that we had and from a standpoint of the property tax levy continuing to go up to subsidize, owning and operating at 1.3 facilities and then two. And you came right on the heels of privatizing Sunny Ridge. And Dale Paul, your predecessor, he did a nice job with that transition. He was a good person, employees were comfortable going to him, but when he retired and we had the opportunity to hire a new individual, of course we were looking for someone who could take on the incredible challenge that you took on and with your background and ability we certainly were blessed with the right person. What have you done in the last year to help reduce the pressure on the property taxes associated with subsidizing Rocky Hill? Well as I started to look at the operation, it became clear to me very early on that this county owned facility suffered from a lot of the same concerns or problems that most county homes that I've dealt with over the years was facing. And that is while they were good at trying to control their cost and rein it in, their cost base started out much higher than the normal privately owned and operated facility from the private sector because of the benefits that county employment offers. And with that, even controlling costs, you're never gonna be able to compete face to face with the private sector. So what we needed to do was look at the revenue side. And as was my experience in the past, while we had a decent size population in the facility, the facility was doing very little to optimize its revenue streams and that became my main focus. I knew again early on that by cutting costs I was not gonna be able to achieve the goals that the county has set out for me which was to maintain that facility in county ownership and keep it a viable entity without continuing to drain the resources of the county to try to do that. And so we had to focus on building revenue and that has been our primary focus going forward. The next question we have is how would you rate your success the past year and let me quickly answer that for you. Okay. Outstanding. Oh, well thank you. Please tell our viewers why. Well, I'm hoping that it's because of some of the achievements that our staff and management team have made out there. So far this year we are running $1.2 million ahead of the revenue streams generated the same time last year. We've converted that into bottom line dollars or in this case savings to the county just over $300,000 so far this year. As compared to last year, we're operating almost three quarters of the million dollars ahead of last year. So we're doing pretty good in moving forward and my only warning is we're just starting. We're just getting going. Kind of warning we like to hear. Our last question before I turn it over to Mike Banderstein. As you think about or reflect down what you've been able to accomplish in the last year which we all know how quickly a year goes by, what are you envisioning or what do you anticipate doing in the year ahead? Continuing a lot of the same successes we've already started hopefully. The management team continues to gel and get better and better at what they've done and what they're doing. I've introduced some financial management type programs to help them understand the cash flow, the way the money moves throughout the organization and give them a real time ability to manage and steer those funds the appropriate way. We're continuing to educate the staff to make them more involved in this entire process. I've been teaching reimbursement to nurse aides since the mid 80s and I don't wanna change that trend. I wanna continue to go that way because I fully believe that the more my staff understands how this business works and moves forward, the better job they will do to help us get there because they're interested not only in providing quality care but interested in sustaining the facility. Very good, thanks Mike. Mike, in the state of Wisconsin about half of the counties don't operate nursing homes. What are some of the advantages and disadvantages you see for Sheboygan County because we do have a nursing home? The advantages or disadvantages sometimes become much more evident than the advantages but the advantages quite honestly are much more profound. The disadvantages are you have a large workforce and with the county's costs and benefits and programs, it's a costly operation to keep going if it's not aggressively run like a business. The advantages though clearly outweigh the disadvantages. The advantages, it gives the county internal resources to deal with the public health issues and county resident health issues that it in a lot of cases is mandated by law or regulation to deal with provides a resource to the county to utilize at a much lower cost than paying outside private resources to provide or other counties to provide. Behavioral health is an easy one that comes to mind that is beginning to be more and more a topic of discussion as the needs become more evident to the county and to the community. There's got to be a place that you can work with these individuals and help them and give them the proper care and that is just one of the voids that we can help fill. Okay, coming from the private sectors you have, why are your early impressions of working for county government comparison? It was an interesting transition and my initial impressions, I'm not sure what my initial impressions were gonna be. I envisioned myself raising a question and a year later still working to try to achieve an answer and quite honestly I have to say that I've been very pleasantly surprised. We've kind of mapped out a strategy with our liaison committee and I've had the pleasure of strong support from both Adam, Bill Gehring before you and now yourself in the chairman's position helping and recognizing what we need to do to make Rocky Noel successful. So I've been very pleased, our liaison committees, both the current one and the previous session committees have just been extremely supportive. We're focusing on the big picture and what we need to do to be successful as a group and they've been extremely supportive and from what I understand from feedback from Adam and some of the other department heads, very liberal in allowing me to move things forward at the rate that we need to move them to be successful and not time things up over long debates. That's great to hear. After being here for a year, do you think that Rocky Noel's getting the support that it needs to be successful? I don't like we change the advertising budget to give you more money to promote the facility and things in that area. Absolutely, I've again been extremely pleased. Any thing that I've been able to present not only to Adam, yourself, our liaison committee or the county board, I've been, as long as I'm able to explain why we need it and make it make common sense to these individuals, they've supported the process. So I have to say, yeah, we really are getting that support. And I know even some of the county board supervisors who've might have been more critical in the past have recognized the improvements that we're making and have extended their hand in offering support and help. So no, I really believe we're getting what we need. Great, I know you touched on this before, but to what extent do you believe the county can really be effective in competing with the private sector in the nursing home area? I think the biggest hurdle the county had to make as an entity was to understand that they were operating a business, a true all no holds barred business. It wasn't just a service that was being provided to the taxpayers, it was a business that they were operating. And while they had structured it appropriately, setting it up in what they refer to in government circles as an enterprise account, it had not necessarily been looked at as a business and a lot of times looked at just a service. So in going forward and realizing that it was a business, we do need to compete. We do need the advertising dollars. We do need to go out and market. We do need to go compete with the private sector. Once that realization was made, the support then was there and I think that's the biggest hurdle that needed to be made was just changing that mindset. Now it's a question of us going out and doing our jobs and being successful. And I'm judging from some of the feedback that I'm getting from individuals attending association meetings and that were being successful because they're wondering how we're able to do what we're doing when some of our counterparts in the private sector or in the non-for-private sector are struggling. What do you see as some of our advantages or disadvantages in competing with the private sector? The advantages are clear on the onset, which I had nothing to do with and it's all back to you guys, is the reputation. The facility has us had a good strong reputation while mostly unknown out there. It was a well-known facility but the people that did know it had positive experiences with it. So that was a definite advantage to start out with. Going forward, the resource, the support of the county is certainly an advantage to us moving forward and it allows us to take some of the more riskier steps in building a business or strengthening our business because we have that foundation that's very strong and not the whole county is funded by this one-payer source or two-payer sources like the private sector is. Change in Medicare quickly cripples the private sector where in our case doesn't necessarily cripple us while it impacts us. We still have the wherewithal to continue to compete. Move forward, so. Excellent. Mike, you made a number of changes already. We know that you're looking to make others to make us successful for the future. How has your experience been with the labor unions who represent the majority of the employees at Rocking All? Remarkably good overall. We're representing, our staff out there is represented by two different locals. One for the professionals, the RNs and the other for what in the industry is referred to as service employees which would cover our LPNs, nurse aides, dietary housekeeping, laundry maintenance staffs. The service industry staff and the union that represents them, AFSCME, 24, 27 has been extremely supportive while leery as any management relationship is typically with labor started out very leery. We have developed a rapport and we're communicating well, I believe, and they understand the need that we have to make some changes if we're gonna keep Rocking All a viable entity and make it successful going forward and that we have to work together to be that way and to be successful and they've embraced it and I want to very much compliment them on that. Our professional group, which is a much smaller unit, is having more of a struggle in making that transition and going forward. They understand that they need to but it's tough. It's a smaller group, less diverse, more focused on certain issues but I too believe there we can and continue to develop a decent line of communication and be successful with them because ultimately the goal is the same. We both, all three of us want to deliver quality care to the people that are in our charge and we also want to maintain and keep the entity known as Rocking All around and successful. Well, thank you for all your efforts in doing that, Mike. Sure. Turn it over to back to Adam. You know, it's probably one of the more pleasurable interviews that we've had regarding our healthcare centers. When I look back 10 years, our 100th program, during the last 10 years, you know, we looked at downsizing from three to two facilities and close comprehensive healthcare center and that was difficult. That had an emotional strain in the community and though it was badly needed because the building was so old and outdated, it was still difficult. Then we looked at privatizing Sunny Ridge and even more of emotional charge throughout the community. People concerned about the residents and what will that mean for the area. And a little over a year and a half ago, the county board made that decision, was perhaps one of the most significant decisions the board's made for our overall financial health as a county. There are 10 nursing homes throughout Sheboygan County so counties certainly don't have to be in the business but we got through that and now we have a level of service that I think we can support.  But you clearly have brought a level of expertise and leadership and energy and can do attitude that we badly, badly needed in this organization. And I'm just so proud of the work that you're doing at Rocky Knoll. One of the things of late that is resonating a little bit in the community, I think from a journal sentinel article about two months ago was some focus on Sunny Ridge and nursing homes throughout the state that have had some incidents. Whenever you have nursing homes and elderly people to care for, accidents happen as they happen as home. And you and I talked about that a little bit and you gave me a perspective that, this can happen at any nursing home. I think our viewers, perhaps by the time they see this program are gonna see an article or focus on this further coming from our own Sheboygan Press. And my understanding is they're gonna take a good look at the nursing homes just in Sheboygan County and touch on what's happening there. Please offer our viewers some perspective, Mike, as to what types of incidents can occur or why does it occur, give them a sense of that. It isn't, frankly, it's not unusual to have from time to time an accident that happens. And then when that does happen, what the response is from the state? Who's keeping an eye on things? Sure, after 35 years in this industry and working with it, obviously, I've seen a lot of change. But to operate a healthcare center like we're operating, probably the best analogy to give the public would be, you're running an ice skating rink but the expectation is nobody ever falls down. Whether they get hurt on the ice or just fall on their butt. It's clearly unrealistic to assume that you can care for so many people that the only reason they're there is because they require a high level of care and intervention that something may not happen. Accidents will happen. The mistake or the problem comes in is when the facility doesn't respond correctly to that accident. While you can't anticipate anything, when a problem does occur, you need to investigate it, look at it, and then take the necessary precautions that are reasonable to try to prevent that type of thing from happening again. And it is in that circumstance where I would have a problem with a healthcare facility if they've experienced problems and they have the same problems over and over again. That's clearly a lapse in management. The dynamics that you have going on is obviously it makes for headlines and headlines then generate pressure on politicians. Politicians generate the pressure on the regulatory agencies. And the agencies quite honestly look at, the feds will look at a state like Wisconsin and go. We're not seeing the degree of deficiencies or citations that we are seeing in certain other areas. We don't think you're looking hard enough. Step it up and the pressure comes on. And sometimes things will start to be cited that weren't cited in the past. Clearly when an injury or an incident happens concerning a resident, steps need to be taken to safeguard not only that resident from it happening again, but other residents from experiencing that same type of problem. And the difference between a good facility and maybe a not so good facility is the fact that a good facility will respond, will take steps, will move forward. But again, that never gives you a guarantee that it cannot or will not happen. All you can do is take reasonable and prudent approaches to preventing and safeguarding these issues. You're dealing with a lot of people.  And my interpretation of what's acceptable versus somebody else is different. Personally, I think it's good when the press raises some attention to this because it hopefully makes all nursing homes perhaps even be a little, even more guarded to the important role they play. And when people weigh in and raise a concern about one facility or another, again, if that raises awareness and leads to better care, that's a good thing. But as you said, these can happen at any time, at any nursing home. And frankly, I'm real proud of the quality of care that I think our nursing homes throughout Sheboygan County provide. We have some good nursing homes. I certainly want Rocky Knoll to be number one and our reputation has been strong. But when we went through that privatization of Sunny Ridge, we had significant bumping and that changes staffing patterns and people are in new areas. And I know at Rocky Knoll we had to work through that. And frankly, I think at Sunny Ridge they still are working through that a little bit. They're relying on more pool help than I know they'd like to. But I just raised that because I know there's been a little bit of attention to it. It's very, very important. And I think we're fortunate that in Sheboygan County we have a lot of good people with wonderful hearts and intentions working in all 10 nursing homes throughout Sheboygan County. We only have a minute. I've got to wrap it up. Mike, I just want to say thank you for the leadership you've provided, the work you've done on the budget with your management team, your staff. It's been fantastic. It's so good to have you as part of our organization. So thanks for joining us today. Thanks. Pleasure to be here. On behalf of Chairman Mike Van der Steen and the County Board, my name's Adam Payne. Again, it was good to have you. And next month our guest will be Rebecca Persek, the Family Court Commissioner. So until then, be well.


Good afternoon, everyone, and welcome. This is Melissa Arma with the stock swashin'. Guess what? Google looks amazing. Beautiful, beautiful, fabulous chart. It's rallying here at two o'clock, major reversal time. It's at about 7.67 with 62. Enough time of the day for this to run up to 7.70, 7.75, 7.80, and beyond. This is a great chart. Google has earnings out this week, April 21st. I'm doing this video for my new best friends, Amy and Elise, because I told them on March 11th that Google was an amazing buy. Low on that day was 7.17, 12, and guess what? Stock has not even touched anywhere near that number since the day that I said to buy Google on that day on March 11th. Look, stock has rallied up non-stop since then. Stock has rallied 50 plus points almost since the low of that day. It hasn't gotten anywhere near. If you bought the day I said to buy it on the day of March 11th, you were never done any money. All you can do is get up every morning and make money, make money, make money, make money, make money, make money. So there you have it. Make a million dollars with the Stock Swoosh. Learn how to trade gaps. The next golden gap class is coming up. It is April 30th and May 1st. Email me at melissathestalkswoosh.com to want more information. Go Google, go, go, and to infinity and beyond. Have a great day everyone.


Hey Izzy. Hello everyone. It looks like everyone's here. Hello. She must ring and let's get started. No one's either okay? Hopefully it's not too small. Yep. Great. Okay. Let's go through the housekeeping first then. So, any trust notice there? If you go to this link here you can read the details. You would have heard the announcement already that this is going to be recorded. So, if you don't want to record it, then you can turn your video off. Yeah, please mute if you, unless you're speaking and if you have a question use the raised hands. Although being small we can probably just, small group here. We can probably just answer on the fly. Okay. Let's start off with some general announcements. I don't see anything listed there. Does anyone have any general announcements they want to make? I'll take that as a note. So, moving past that. We're doing the roadmap listed here. I don't think there's anything new added to the roadmap. Since we looked at it last time. No. So, this is Shanghai upgrade. I think it was last time we hit in the 23rd. Actually, there's been a recent modification. I can't see what it is. But currently we're focused, we'll be focused on the Shanghai upgrade. I don't think there's anything else to talk about in the roadmap right now. There's probably some, in terms of Shanghai. There's been some detail thing added here to the next upgrade though. I don't think there's anything to base it to the Cancun upgrade. Is there anything anyone want to discuss on the roadmap? But we're going to come to the rest of the call. Make sure this is the right one. So, we've got the release rotations. See that in the Contributor channel, there's been a post date for March 8th for the next release. This also has the date for the post date there. So, what were people's thoughts on the next release dates? So, this last one was a bit later than we had hoped. So, I think this one moves it back to a Wednesday. I think we did strictly two weeks from this. I think this was a Friday that wouldn't have worked with a typical schedule. So, that's why I believe that was moved. I think Simon, you raised this. Did you get a sense if there was a consensus on March 8th being the release date? Everything I've heard so far has been a favour of it. I haven't heard anyone object to it. Okay. Well, that sounds promising. Yeah. Okay. So, as far as we know so far, the next one will be March 8th. And then from onwards, we'll plan to continue doing the two-week releases for the point releases in the 23.1 series. So, that's the case. Yeah, I think we basically got to more or less the end of this week to make a call, because we have to start burning in at the end of this week. Yeah. I guess it's probably too late to be any sooner than March 8th. Yeah. And I think that one of the key things we wanted in that, ideally, would be the Gaulie Shanghai configuration, if it's available. Yes, I do. And Lisa's just saying we should have the Gaulie slot decided this week on the All Four Devs call. So, that should work out nicely. So, we should know in the next few days when Gaulie should happen, and we'll have enough time to include that in the next release. Yeah. I think it probably depends on how Sepolio goes, but it's a success for rollout. We should be able to define Gaulie in a minute. Next. Yeah. Yeah. So, fingers crossed, Sepolio works as well. We'll find out in a few hours. Now, segue that. The Shanghai Epic. So, I might just open this epic up. I think you're probably the person to talk to this, so I'm not going to see your face there on there. Did you want to give a quick update on the, how we're going with the Shanghai withdrawals? Sure. Yeah, I'll keep it brief, but feel free to ask any questions. Basically, all the kind of main bits of the code are done. The things that are still in progress and still to do are related to adding in more tests and improving the robustness of, well, our test code, because there's quite a few different frameworks involved. And yeah, we obviously, as mentioned on track for this, Sepolio release in three hours. And yeah, if there's no issues with that, should go smoothly with the Goli one as well. There's minimal work to do, just configurations to add in for that. And then hopefully onto mainnet. So hopefully by the time we're on mainnet, we'll have had all of these items in the Epic complete and we'll have all regression tests in place and we'll be in a good place. But alongside this, there's also DevNet's running as well as the test nets, the public test nets. So we should be pretty confident, I think, if we don't see any problems in that. All right, that sounds good. So we'll just put it in there. So ready for, and we've put an item here for work update on the improtocol deposits by an external contributor. Does anyone have any details on? Yeah, I put that one in there as well. I wanted to bring this up because it's an external contributor to the base, which is good. It's actually, I found out they have come in through the Ethereum protocol fellowship, I believe. Which is like a kind of mentorship program. And Mikhail is leading this project. Doing the improtocol deposits, this EIP is part of. There's another change to do with the execution API as well. That counts part to this. And yeah, so Mikhail is driving that and he's also the mentor for this contributor that has opened up PR and Basu. So we're just working through, but it's good that they, I think the mentee was given a choice and chose Basu to like effectively prototype this EIP on, which is really good news, I think. Yeah, it's exciting to see Basu used as a reference implementation for this or early work on this EIP. Anyway, so. Also the change itself is really good because it means we can get rid of the beacon chain having to like do stuff with the deposit logs and just makes everything work a lot nicer and lock some features in Basu like post-merge checkpoints in as well for validators. Yeah, definitely. I'm not sure there's much to add to this is probably bring more awareness, but you did have one question here was any reason not to include this on main using the experimental experiment EIP's time so feature toggle. So I guess that's it. I'm not sure if we'll necessarily be able to answer it here, but do you want to explain what you were asking there? So. Yeah, so. Dano introduced recently, I guess driven by some of the EOF changes. Two new forks that are like internal kind of feature toggle forks. There's a future EIP's time and an experimental EIP's time future is intended to be. An upcoming fork, but I guess hasn't got a name yet. So anything that we know is in Cancun can go in Cancun, but anything to the next one would be future. And this experimental one, I guess, is things that haven't been agreed to go into a fork yet, but we still might want an implementation, but this reason, for example, prototyping. So yeah, it's the first time, I think, including anything in this experimental EIP's time fork. So. It was worth bringing up and seeing if it was appropriate. And yeah, if anyone had objections to this particular EIP going in there, because it is quite early days for this EIP. It's not going to go in Cancun apparently. Right. Okay, so we're going to have it for six months or more probably. Yes. Yeah. Okay. Do you have any thoughts on that? Maybe this is the kind of discussion we need to have on the contributors. I'm going to go through a few more people's thoughts on that. It seems like we could use the experimental EIPs. I think that's exactly what it was intended for. But okay, so no one's going. So we'll see, maybe we'll just bring to the water. But we've still got time to win the most that PR in so we can get them. Okay, I have the discussion on the. And I can shoot it as a. Discord. See if anyone has any thoughts on that. And if anyone is up for reviewing this PR as well, the contributor was welcoming some early reviews, even though it's in draft. Right. Yeah. So it's going to see someone doing some, some of these, some of these EIPs for us. Okay. That's it as far as work updates. We've got a few items here in the other business. I think this is your item here. I'm selling on the most. I think it did you want to. What this is about and. Yeah. Yeah. So this is a feature in GitHub that is currently in beta. I have tested it out in some. Two other like test repositories. We haven't tested them basically yet, but it looks cool. It looks easy to use. It's essentially the same as enabling auto merge, like if another PR gets merged in the meantime, and you would normally need to merge from main again, it just handles that for you. So it essentially manages any PRs with whether you've hit the button to add it to the queue. It manages it as a queue. The only real change to how we currently work is that if you want to. So when you set up merge queue, you choose squash commit sounds like the strategy to merge. And how we work now is when you hit the auto merge button, you get to edit the commits at that point. So the change would be that if you wanted to squash the commits and edit the message, you would need to do that manually on your PR. Before you add it to the merge queue. So that's kind of really the only change to the way that we work right now. So my question is, can we turn it on? Can we try it out? Do we, like, we probably don't want to enable it in the middle of doing a release, you know, just in case there are side effects, but maybe after the release, maybe before the release. Any objections, any concerns, any questions? So just, once this features on everyone, this will be the only way to merge. Will they use the merge queue? Yes, correct. So if you, so when you set it up, it's not called enable the merge queue. It's called do you want PRs to, like, do you require a merge queue? So it just means that, yeah, even if there's only one PR being merged, it will just be managed as a queue. Yeah, I don't have any objections to it. I think it's, could help us. Maybe less so in our time zone. I haven't had too much of an impact upon to re-merge, but certainly at times it happens. It looks like Simon just voiced his approval of that. And I see a thumbs up from Stefan. That sums up and so far as well. That's good. Awesome. I'm going to any objections. Like I said, I think that the timing would be, we don't want to do it just before release. That would be the only thing. We want to make sure. Oh, thanks, good idea. Did you, and you haven't heard any objections in this call at all? No, the only questions around the squash commits, but it just would mean that you would want to do that manually. In advance. There was a related question. I think related. You think you said that you could actually get it to default the message in the squash commit to the description. Entitled. Yes. Yes. So that's another option when you set it up is that. When your squashing commits, you can. So the default, which is what we have right now is. It just appends all of the commit messages together. Another option is. You have the PI description. And I think the son, like the author's name. And that's it. So you could set that up, but then you'll, you'll lose everything in the commit messages. Right. So. Okay. I'm not hearing any objections to that. I think we should. I think you have to go ahead to. Put that. Yeah. So maybe tentatively we say. After this next release. Yeah. And maybe we just need to write up a little. A blurb on. The merge commit piece. And. How that works. Yeah. And if we don't like it, I guess it's easy enough to turn that off. Yeah, absolutely. It's still bigger. So there might be. Problems. Okay. And I think the other piece we want to think about, which has come up before is we commonly get. Merge conflicts in the changelog. So I think if we, you know, have a sensible ordering in the changelog, so that we're not always, you know, adding to the last line. That should sort of. Eliminate a lot of conflicts as well. I think that has become.  I think that has become better, but wait and see, I guess we. Thanks. You can try it out first, because no, you can do that. That's fine. All right. that sounds good. Shore Kelvin. it's a final call to remove the base who knows this core channel. So yeah, I think we did discuss this before actually. I think this was Simon that brought this up previously. Yes, I hear you've got, you've both even got the notes here. Thank you. So on December, so that's a few months ago. So we've had some discussion. Simon, would you be able to, I guess, I don't know where the discussion's got to with the base who knows this core channel? Sure. The discussion was it was kind of old. So I'm kind of bringing it up again, really. But I think I think there was only one objection from Dano. Not an objection as such, but more clarification of why I think he created the two separate channels or requested them to be created originally, which was after the merge. We were getting a lot of support questions and I think he wanted to feel like distinguished between things that were like supporting how to run a node versus questions about base to itself, like basic features and things like that. I don't think like in my experience, people use the base who channel and the base who knows channel interchangeably. There was a suggestion to change it to base who supports instead, which is probably more clear than basic nodes, but I still think users would just use both of them. I think they have the same intent, really. It's just that they happen to be quite a bit of noise before. And that's mostly gone away now. So I would, yeah, I would still favor removing basic nodes and just using basic maybe we can split it out again. If there's a problem in the future, but I will, since Dunno gave maybe something of an objection before I will think him specifically on this floor to check that he's OK. So OK, I'll just put that in there. So there's been no other objections to removing it from what you were saying. No, no, no, it's certainly the objections. There would, yeah, there would obviously be a small deprecation window would be appropriate, I think. Or at least just making sure that all of the questions have been answered or moved over to the other channel before we actually get rid of it. OK, so that's brought up an interesting point. So that there's been much less users of usage of the base in those channels as well. So, yeah, I can't find the link right now. I can dig it up, but it's basically the insights in the discord server. And yeah, at the channel level, they still had, like, I don't know, four or five, ten times the traffic by numbers of messages compared to basic nodes. Which I think supports a view that it was useful initially, but less so now. So, yeah, I think you're right there. And if I'm summarizing this correctly, it seems that there's no objections than the plan would be to give some notice and then deprecate to remove that channel. Yeah, so I'm happy to kind of go in that. OK, great. That's not just, yeah, I think it makes sense to get rid of, like Sally said, the there's not being much usage in that people confused between between that channel, the other channel, I think, unfortunately. But I think we need both either of them. It's in the volume. Yeah, I think that's probably all the same on that one. Just so you're going to follow up on that. Simon with with with Dono and yeah. Yeah, OK, great. Now, that'd be good to go down with another channel. Is there anything else anyone wants to discuss? OK, I don't think that is a no, it's kind of like this, yeah. And is there anything we want to add to the next call? But we don't get a chance to discuss this time, I guess. We might probably think of that later. Which case I will stop sharing the screen now. Looks like that's it for the contributors film. Thank you, everyone. Thank you, Jason. Thank you. Thanks, Jason. Thank you. Thanks. See you. Yeah.


Days of heavy rains in early November have caused Northern France's rivers to overflow and flooded houses and fields, prompting the evacuation of residents, with some having to be airlifted to safety. Over 260 villages and towns, comprising at least 6,000 residences have been affected, according to authorities. While rivers have stopped overflowing in most parts, some areas remain underwater. Businesses have also been hit hard by what the French government has declared to be a natural disaster in most of the regions affected. In all, the state-owned Caisse-centrale de reassurance-re-insurance company says damages may reach up to $599 million. French President Emmanuel Macron's government has promised it would cover, for six months, the relocation costs of residents of the 181 municipalities recognized as having been hit by a natural disaster. Finance Minister Bruno Le Maire has also urged insurers to act swiftly and without net-picking.