[Discovery] RAID 0, RAID 1, RAID 5, RAID 10 Explained with Diagrams

RAID stands for Redundant Array of Inexpensive (Independent) Disks.

On most situations you will be using one of the following four levels of RAIDs.

  • RAID 0
  • RAID 1
  • RAID 5
  • RAID 10 (also known as RAID 1+0)

This article explains the main difference between these raid levels along with an easy to understand diagram.

In all the diagrams mentioned below:

  • A, B, C, D, E and F – represents blocks
  • p1, p2, and p3 – represents parity

RAID LEVEL 0


Following are the key points to remember for RAID level 0.

  • Minimum 2 disks.
  • Excellent performance ( as blocks are striped ).
  • No redundancy ( no mirror, no parity ).
  • Don’t use this for any critical system.

RAID LEVEL 1

Following are the key points to remember for RAID level 1.

  • Minimum 2 disks.
  • Good performance ( no striping. no parity ).
  • Excellent redundancy ( as blocks are mirrored ).

RAID LEVEL 5


Following are the key points to remember for RAID level 5.

  • Minimum 3 disks.
  • Good performance ( as blocks are striped ).
  • Good redundancy ( distributed parity ).
  • Best cost effective option providing both performance and redundancy. Use this for DB that is heavily read oriented. Write operations will be slow.

RAID LEVEL 10

Following are the key points to remember for RAID level 10.

  • Minimum 4 disks.
  • This is also called as “stripe of mirrors”
  • Excellent redundancy ( as blocks are mirrored )
  • Excellent performance ( as blocks are striped )
  • If you can afford the dollar, this is the BEST option for any mission critical applications (especially databases).

REF: http://www.thegeekstuff.com/2010/08/raid-levels-tutorial/

Advertisements

[Discovery] Thực hư chuyện tháp nghiêng Pisa sẽ đổ trong tương lai?

Nhắc đến nước Ý lãng mạn, chúng ta khó có thể quên được một di tích nổi tiếng – tháp nghiêng Pisa. Tuy nhiên ít ai biết được rằng, tháp nghiêng Pisa liên tục “chao đảo” trong suốt 840 năm kể từ ngày khởi công đầu tiên.

Tháp nghiêng Pisa đã từng “nghiêng ngửa” như thế nào?

Trên thực tế, tòa tháp huyền thoại này đã bắt đầu nghiêng từ những năm 1173, khi mới chỉ vẻn vẹn 3 tầng được xây. Nguyên nhân được cho là vật liệu làm móng của tháp có mật độ không ổn định. Vì lý do này mà tháp bị nghiêng về phía Bắc. Để khắc phục tình trạng này, ngay từ những ngày đầu, các nhân công đã quyết định “bù” lại độ nghiêng của tháp bằng cách xây cột và mái vòm ở tầng 3 cao hơn một chút về phía bị nghiêng. Tầng thứ 4 của tháp nghiêng Pisa cũng được xây dựng ngay sau đó.

Từ năm 1173 trở đi, tháp nghiêng Pisa vẫn lắc lư trong suốt 100 năm. Nhưng sự việc không chỉ dừng lại ở đó, khi mà móng tháp bị xẹp xuống không đồng đều. Vào năm 1272, tháp Pisa thậm chí còn “nghiêng về phía nam”. Một lần nữa, các kỹ sư lại quyết định “bổn cũ soạn lại” – xây dựng tầng thứ 5 để bù độ nghiêng của tháp. Sau 1 thời gian cải tạo, đến năm 1278, công trường xây dựng tháp Pisa lại bị bỏ dang dở với chỉ 7 tầng xây xong.

Đầu thế kỉ 14 là thời kì mà tháp nghiêng Pisa đã thật sự đứng giữa ranh giới “kì quan” và “phế liệu”. Thấp 1 lần nữa lại chao đảo và lần này độ nghiêng đã đạt tới mức báo động đỏ. Có lẽ vì tiếc công sức trong 300 năm vừa qua nên các kiến trúc sư quyết tâm cải tổ lần cuối cùng tháp nghiêng Pisa. Dự án sau cùng cũng được hoàn thiện vào giữa năm 1360 – 1370, với việc bổ sung thêm chiếc chuông khổng lồ trên tầng 8 tháp nghiêng Pisa.

Tưởng như tháp nghiêng Pisa có thể đi vào hoạt động ổn định sau khi hoàn thiện. tuy nhiên cho đến cuối thế kỉ 16, sau sự kiện Galileo Gallilei thả viên đạn đại bác từ đỉnh tháp xuống, người ta vô tình đã biết được tháp bị nghiêng 3 độ so với phương thẳng đứng. Đến năm 1911, các kiến trúc sư vô tình phát hiện ra một sự thật gây chấn động toàn nước Ý: Đỉnh tháp Pisa nghiêng từng 1.2 mm 1 năm.

Vào năm 1935, các kỹ sư xây dựng đã củng cố lại móng của tháp Pisa. Công việc đã được tiến hành bằng cách đổ hỗn hợp xi măng vào mạng lưới các lỗ được đào ở dưới móng. Rất đáng tiếc vì đây là 1 tính toán sai lầm của các kỹ sư, khi mà việc này lại vô tình “đốn” tháp nghiêng Pisa khiến nó sập nhanh hơn. Rất may là hàng loạt các biện pháp gia cố đã được thực thi kịp thời, trước khi “kì quan thế giới hiện tại” bị biến thành 1 đống gạch vụn thật sự.

Vào năm 1989, có một công trình tương tự như tháp nghiêng Pisa được tiến hành xây dựng nhưng ít người biết đến là tháp nghiêng Pavia. Sở dĩ ít người biết là do “tháp nghiêng Pavia” sau khi xây xong chỉ còn là 1 đống đổ nát.

Việc này khiến các quan chức Italia lo sợ trước nguy cơ thành tựu hàng trăm năm bị đổ xuống sông xuống biển, trong khi ngày lễ ra mắt công chúng đang gần kề. Một liên minh các kỹ sư hàng đầu từ các quốc gia được thành lập nhằm “cứu vớt” tháp nghiêng Pisa. Sau cùng, liên minh cũng đồng ý với phương án của John Burland – chuyên gia về các vật liệu cơ học – với phương án rút bớt đất ở phần móng phía bắc tháp Pisa. Việc này đã được tiến hành trong vòng vài năm.
Khi dự án hoàn thành vào năm 2001, “liên minh cứu hộ tháp nghiêng Pisa” đã kéo được tòa tháp khổng lồ dựng thẳng đứng lên 44 cm. Đây là kết quả khiến các chính trị gia rất hài lòng và tự tin đưa vào hoạt động. Kết quả còn tuyệt vời hơn nữa khi mà đến tận tháng 5 năm 2008, các cảm biến theo dõi không phát hiện được thêm bất cứ một cm bị xê dịch nào của tháp nghiêng Pisa.

Liệu nước Ý có thể “kê cao gối ngủ” trước vấn đề nghiêng của tháp Pisa?

Dự án của John Burland giữ tháp Pisa “thẳng đứng” nếu xét trên góc độ “lý thuyết”. Thực tế còn một vấn đề rất đáng lo ngại là các tầng của tháp nghiêng Pisa có dấu hiệu giảm chất lượng theo thời gian. Thậm chí chỉ một trận động đất nhỏ cũng có thể khiến một trong các tầng của tháp Pisa sụp đổ dễ dàng. Tuy nhiên theo ước tính của các kỹ sư xây dựng, tháp nghiêng Pisa sẽ còn đứng vững được trong ít nhất 200 năm nữa. Thêm vào đó, với trình độ khoa học kỹ thuật hiện đại, tháp nghiêng Pisa sẽ có thể được tăng thêm ít nhất … 800 năm tuổi thọ. Chắc hẳn người dân Italy sẽ không khoanh tay đứng nhìn di tích hàng nghìn năm của tổ tiên bị thời gian hủy hoại.

Tham khảo: Howstuffworks

[Dev Tip] Compare two objects

Sometime, you need to compare objects. Beside of override the Equal(), GetHashCode() methods, which are for some domain rules.

If you must compare all properties of the object, then I suggest another way to get it done: using JSON.

You can serialize those objects and compare JSON results.


public static void AreEqualByJson(object expected, object actual, string message = "")
{
var settings = new JsonSerializerSettings
{
PreserveReferencesHandling = PreserveReferencesHandling.All
};

var expectedJson = JsonConvert.SerializeObject(expected, settings);
var actualJson = JsonConvert.SerializeObject(actual, settings);
Assert.AreEqual(expectedJson, actualJson, message);
}

[Dev Tip] The GetHashCode() and Equals() in the implemented IEqualityComparer interface

When you compare two objects using an EqualityComparer then the IEqualityComparer.Equals and IEqualityComparer.GetHashCode methods are used instead of the methods on the Key objects.

# Recall

Every object in .NET has an Equals method and a GetHashCode method.

The Equals method is used to compare one object with another object – to see if the two objects are equivalent.

The GetHashCode method generates a 32-bit integer representation of the object. Since there is no limit to how much information an object can contain, certain hash codes are shared by multiple objects – so the hash code is not necessarily unique.

A dictionary is a really cool data structure that trades a higher memory footprint in return for (more or less) constant costs for Add/Remove/Get operations. It is a poor choice for iterating over though. Internally, a dictionary contains an array of buckets, where values can be stored. When you add a Key and Value to a dictionary, the GetHashCode method is called on the Key. The hashcode returned is used to determine the index of the bucket in which the Key/Value pair should be stored.

When you want to access the Value, you pass in the Key again. The GetHashCode method is called on the Key, and the bucket containing the Value is located.

# Example

BoxEqualityComparer boxEqC = new BoxEqualityComparer(); 

Dictionary<Box, String> boxes = new Dictionary<Box, string>(boxEqC); 

Box redBox = new Box(100, 100, 25);
Box blueBox = new Box(1000, 1000, 25);

boxes.Add(redBox, "red"); 
boxes.Add(blueBox, "blue"); 

[Photograph] Choáng ngợp trước vẻ đẹp của những địa danh nổi tiếng từ góc nhìn trên cao

Nhóm AirPano bao gồm những thành viên ưa thích du lịch mạo hiểm đã thực hiện một chuyến đi vòng quanh thế giới và chụp lại những bức ảnh vô cùng ấn tượng từ góc nhìn trên cao. Họ đã sử dụng một chiếc máy bay để có thể chụp lại những địa danh nổi tiếng trên thế giới, những nơi mà họ đã từng đi qua. Danh sách những địa danh này dự kiến ở con số 100, tuy nhiên nhóm AirPano cho biết họ sẽ còn tiếp tục những chuyến đi của mình.

Những bức ảnh của nhóm AirPano bao gồm cả những địa danh tự nhiên như những thác nước hay các đỉnh núi, cũng như cả những thành phố lớn trên thế giới như New York hay Dubai, và có cả Vịnh Hạ Long của chúng ta.

Những bức ảnh này cho chúng ta một cái nhìn hoàn toàn khác về những địa danh này. Nó cho chúng ta thấy sự hùng vĩ của tự nhiên cũng như của những công trình do con người xây nên.

Chúng ta hãy cùng chiêm ngưỡng những bức ảnh ấn tượng nhất trong bộ ảnh của nhóm AirPano:

Thành phố Dubai.

Thành phố Dubai.

Thác nước Falls Angel ở Venezuela.

Thác nước Angel ở Venezuela.

Nhà thờ Sagrada Familia tại thành phố Barcelona.

Nhà thờ Sagrada Familia tại thành phố Barcelona.

Thác nước Falls Victoria tại Zambia.

Thác nước Victoria tại Zambia.

Thác nước Iguasu tuyệt đẹp tại Argentina.

Thác nước Iguasu tuyệt đẹp tại Argentina.

Đỉnh núi Everest.

Đỉnh núi Everest.

Khải hoàn môn tại nước Pháp.

Khải hoàn môn tại nước Pháp.

Tòa nhà Empire State tại thành phố Manhattan.

Tòa nhà Empire State tại thành phố Manhattan.

Miệng núi lửa Plosky Tolbachik tại Nga.

Miệng núi lửa Plosky Tolbachik tại Nga.

Một góc thành phố Manhattan.

Một góc thành phố Manhattan.

Bờ biển Barrier Reef tại Úc.

Bờ biển Barrier Reef tại Úc.

Taj Mahal tại Ấn Độ.

Ngôi đền Taj Mahal tại Ấn Độ.

Vịnh Hạ Long của Việt Nam.

Vịnh Hạ Long của Việt Nam.

Những tảng băng nổi trên bờ biển của Iceland.

Những tảng băng nổi trên bờ biển của Iceland.

Toàn lâu đài Neuschwanstein tại Đức.

Toàn lâu đài Neuschwanstein tại Đức.

Kim tự tháp tại Ai Cập.

Kim tự tháp tại Ai Cập.

Thành phố Singapore nhìn từ trên cao.

Thành phố Singapore nhìn từ trên cao.

[Dev Rule] 11 Rules All Programmers Should Live By

I am a person who tends to live by rules.

Now granted, they are mostly rules I set for myself—but they are still rules.

I find that creating rules for myself helps me to function better, because I pre-decide things ahead of time instead of making all kinds of decisions on the fly.

Should I go to the gym this morning?

Well, my rule says that on Wednesdays I go to the gym and today is Wednesday, so I am going to the gym—that settles it.

This week, as I was thinking about some of the kinds of rules I impose on myself, I thought it might be a good idea to come up with a set of rules that I think all software developers should live by.

Now, I’ll admit, most of these rules are more of guidelines, but anyway, here they are:

1: Technology is how you get to the solution, it is not THE solution

We can get really carried away with the latest JavaScript framework—ahem, Angular—IoC container, programming language or even operating system, but all of these things are not actually solutions to the problems we are trying to solve as programmers, instead they are simply tools that help us solve the problems.

We have to be very careful not to get too crazy about a particular technology that we happen to like or that happens to be oh so popular right now, lest we run the risk of thinking about every problem as a nail, just because we happen to be holding a shiny hammer we just learned about.

2: Clever is the enemy of clear

When writing code, we should strive to write code that is clear and easy to understand.

Code that clearly communicates its purpose is much more valuable than code that is obscure—no matter how clever it may be.

It’s not always true, but in general, clever is the enemy of clear.

It’s usually true that when we write code that is “clever,” that code isn’t particularly clear.

It’s important to remember this rule whenever we think we are doing something particularly clever.

Sometimes we write clever code that is also clear, but usually that is not the case.

If you’re interested in writing clean code I highly recommend you check out The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin)

code

3: Only write code if you absolutely have to

This one might seem a little contradictory, after all, isn’t our job as programmers to write code?

Well, yes and no.

Our jobs may involve writing code, but we should still strive to write as little of it as possible to solve the problem we are trying to solve.

This doesn’t mean we should make our code as compact as possible and name all our variables using single letters of the alphabet. What it does mean is that we should try to only write code that is actually necessary to implement the functionality that is required.

Often it is tempting to add all kinds of cool features to our code or to make our code “robust” and “flexible” so that it can handle all different kinds of situations. But, more often than not, when we try to guess about what features would be useful or we try to pave the road to solve for problems that we think might exist in the future, we are wrong.

This extra code may not add any value, but it can still do a lot of harm. The more code there is, the more chances for bugs and the more code that has to be maintained over time.

Good software engineers don’t write code unless it’s absolutely necessary.

Great software engineers delete as much code as possible.

4: Comments are mostly evil

I’m not a big fan of writing comments in code. I’m with Bob Martin, when he says:

“Every time you write a comment, you should grimace and feel the failure of your ability of expression.”

Clean Code: A Handbook of Agile Software Craftmanship

This doesn’t mean that you should never write comments, but for the most part they can be avoided and instead you can focus on doing a better job of naming things.

Comments should only really be written when it’s not possible to clearly communicate the intent of a variable or method by using a name. The comment then serves an actual purpose that could not be easily expressed in the code.

For example, a comment could tell you that this strange order in which some operation was occurring in the code was not a mistake, but was intentional because of a bug in the underlying operating system.

In general though, comments are not only evil because in many cases they are necessary, but also because they lie.

Comments don’t tend to get updated with the rest of the code and this results in the comments actually becoming dangerous, because they very well could steer you in a completely wrong direction.

Do you check every single comment against the code to make sure the code is actually doing what the comment says? If so, what is the point of having the comment? If not, how can you trust that the comment is telling you the truth?

It’s a pickle, so it’s best to avoid it as much as possible.

Ok, haters, go ahead and leave your torrent of “comments” in the comment section below, but I’m not changing my stance on this one.

5: Always know what your code is supposed to do before you start writing it

It seems obvious, but it isn’t.

How many times have you sat down to write code without fully understanding what the code you were writing was actually supposed to do?

I’ve done it more times than I’d like to admit, so this is a rule that I need to read often.

Practicing test driven development (TDD) can help here, because you literally have to know what the code is going to do before you write it, but it still doesn’t stop you from creating the wrong thing, so it’s still important to make sure you absolutely, 100% understand the requirements of the feature or functionality you are building before you build it.

6: Test your sh—code before you ship it

Don’t just toss your code over the wall and have QA pound on it only to send it back to you so that you can waste a bunch of everyone’s time with unnecessary bug reports and resolutions.

Instead, take a few minutes to run through the test scenarios yourself, before you call your code done.

Sure, you won’t catch every bug before you pass your work on to QA, but you’ll at least catch some of the stupid and embarrassing mistakes that we all make from time-to-time.

Too many software developers think that it is only QA’s job to test their stuff. It’s simply not true. Quality is everyone’s responsibility.

Stack of open books

 7: Learn something new every day

If you didn’t learn something new today, you just made backwards progress, because I can guarantee you forgot something.

It doesn’t take a lot of time to learn something new each and every day.

Try spending just 15 minutes or so reading a book—I read a whole lot of books last year, just reading about 45 minutes each day on average.

The little advances you make each and every day add up over time and will greatly shape your future. But, you have to start investing now if you want to reap the rewards later.

Besides, today technology is changing so rapidly that if you aren’t continually improving your skills and learning new ones, you are going to be left behind very quickly.

8: Writing code is fun

That’s right. You probably didn’t get into this profession just because it pays well.

I mean, there is nothing wrong with picking a job that pays well, but doctor or lawyer would have probably been a better choice.

Most likely you became a software developer, because you love writing code. So, don’t forget that you are doing what you love.

Writing code is a lot of fun. I wish I could write more code.

I’m usually too busy keeping this business going to spend much time writing code these days, which is one of the reasons why I so clearly remember how much fun it is.

Perhaps you forgot that writing code is fun. Perhaps it’s time to remember how much fun it is again, by starting a side project or just changing your mindset and realizing that you get to write code and you are even paid for it. (Hopefully)

9: You can’t know it all

As much as you learn, there is still going to be a lot you don’t know.

It’s important to realize this because you can drive yourself nuts trying to know everything.

It’s OK to not have all the answers.

It’s OK to ask for help or to speak up when you don’t understand something.

In many cases, you can learn what you need to know pretty darn close to when you need to know it—believe me, I do it all the time.

My point is, don’t get caught up in trying to learn it all, when that is an impossible task. Instead, focus on learning what you need to know and building the skills that enable you to learn things quickly.

10: Best practices are context dependent

Is test-driven development, the best way to write code?

Should we always pair program?

Are you a scrub if you don’t use IoC containers?

The answer to all of these questions is “it depends.”

It depends on the context.

People will try to shove best practices down your throat and they’ll try to tell you that they always apply—that you should always do this or that—but, it’s simply not true.

I follow a lot of best practices when I am writing code, but I also conditionally don’t follow them as well.

Principles are timeless, best practices will always be situational.

11: Always strive to simplify

All problems can be broken down.

The most elegant solutions are often the most simple ones.

But, simplicity doesn’t come easy. It takes work to make things simple.

The purpose of this blog is to take some of the complexities of software development, and life in general, and make them simple.

Believe me, this isn’t an easy task.

Any fool can create a complex solution to a problem. It takes extra effort and care to refine a solution to make it simple, but still correct.

Take the time. Put forth the effort. Strive for simplicity.

[Discovery] Chất điện phân mới giúp loại bỏ sự hình thành của sợi dendrite gây đoản mạch pin Li-ion

Dendrite. Hình ảnh hiển vi cho thấy chất điện phân thông thường tạo điều kiện cho sợi dendrite phát triển (hình a) trong khi chất điện phân của PNNL khiến Lithium hình thành dạng nốt nhỏ, không gây đoản mạch(hình b).

Dendrite là một loại sợi dẫn điện mỏng thường hình thành bên trong pin Lithium khiến cell pin giảm tuổi thọ và là tác nhân gây cháy nổ. Mới đây các nhà khoa học tại phòng thí nghiệm quốc gia tây bắc Thái Bình Dương (PNNL) thuộc bộ năng lượng Hoa Kỳ đã công bố họ đã tạo ra một chất điện phân mới cho pin Lithium với khả năng không chỉ loại bỏ hoàn toàn sợi dendrite mà còn hứa hẹn tăng hiệu suất sử dụng pin và cải thiện dung lượng.

Rất nhiều loại pin sạc sử dụng trên các thiết bị di động hiện nay dùng công nghệ Li-ion – gồm 2 điện cực, 1 cực dương bằng Lithium, 1 cực âm bằng graphite (than chì) và dùng chất điện phân hóa học. Về cơ bản, chất điện phân chứa các electron mang điện và đóng vai trò trung gian truyền tải dòng điện giữa các điện cực khi pin được nối vào một mạch điện. Khi xả pin, Lithium rời khỏi bề mặt cực dương và bám vào cực âm, ngược lại khi sạc pin, Lithium kết tụ trở lại trên cực dương. Qua thời gian sạc/xả, bề mặt cực dương hình thành các sợi dendrite và các sợi này sẽ mọc dài hơn khi Lithium liên tục lắng đọng.
Các sợi dendrite phá vỡ đường dẫn điện tích thông thường và tạo ra các đường dẫn lộn xộn xuyên suốt cấu trúc pin. Một khi sợi dendrite mọc đủ dài, xuyên qua lớp điện phân và kết nối trực tiếp cực âm với cực dương thì pin sẽ bị đoản mạch.

Kết quả là pin tự xả không thể kiểm soát làm giảm tuổi thọ pin. Ngoài ra, sợi dendrite còn khiến pin nóng lên, gây phản ứng tỏa nhiệt và phát nổ dù đang để ở ngoài hay bên trong thiết bị di động.

Sợi dendrite mọc rất nhanh từ cực dương và chạm đến cực âm.

Để ngăn ngừa sự hình thành của sợi dendrite, một số nhà nghiên cứu đã thử nghiệm một số giải pháp như bổ sung một lớp phủ chứa các quả cầu carbon cho cực dương của pin hoặc điều chỉnh công thức chất điện phân với một số phụ gia hay thậm chí là cho thêm sợi nano Kevlar vào hỗn hợp này. Tuy nhiên, sợi dendrite thì vẫn cứ mọc mà không có dấu hiệu bị hạn chế.

Chất điện phân mới được PNNL phát triển nhắm đến mục tiêu thay thế hoàn toàn chất điện phân đang được sử dụng trên pin Li-ion bởi nó không tạo điều kiện cho sợi dendrite hình thành. Thêm vào đó, nó cũng tăng dung lượng và hiệu năng của pin.

Tiến sĩ Ji-Guang “Jason” Zhang đến từ PNNL cho biết: “Chất điện phân mới của chúng tôi giúp tăng 99% hiệu suất của pin Li-ion và nâng mật độ dòng điện lên 10 lần so với công nghệ trước. Phát hiện mới của chúng tôi có thể khởi động quá trình phát triển các thế hệ pin sạc tiếp theo hữu dụng và mạnh mẽ hơn chẳng hạn như pin Lithium-lưu huỳnh (Li-sulfur), pin Lithium-khí và Lithium-kim loại.”

Dựa trên một nghiên cứu cho thấy các chất điện phân chứa nồng độ muối cao có thể cản trở sự thình thành của sợi dendrite, tiến sĩ Zhang cùng các cộng sự đã sử dụng một lượng lớn muối Lithium bis(fluorosulfony)imide, một hợp chất silicon hữu cơ và dung môi dimethoxyethaein để tạo ra chất điện phân.
Dendrite_01.

Hình ảnh hiển vi cho thấy các sợi dendrite mọc dài trong pin Li-ion.

Để thử nghiệm hỗn hợp mới, nhóm nghiên cứu đã tạo ra một cell pin hình tròn có đường kính dưới 25 mm. Khi cell được sạc, thay vì các sợi dendrite xuất hiện và mọc dài ra, điện cực Lithium lại sản sinh một tấm mỏng có các nốt Lithium nhỏ trên bề mặt và chúng không tác động được đến chất điện phân gây đoản mạch pin.

Nhóm sau đó tiếp tục thí nghiệm cell pin với hơn 1000 chu kỳ sạc/xả và cho biết cell vẫn duy trì được 98,4% điện tích ban đầu và mật độ dòng điện khoảng 4 mA/cm2. Khi thay đổi mật độ dòng điện, hiệu suất của pin cũng bị tác động. Theo đó nếu duy trì mật độ 10 mA/cm2 thì hiệu suất của pin đạt xấp xỉ 97% trong khi nếu giữ mật độ 0,2 mA/cm2 thì hiệu suất tích điện của pin có thể đạt đến 99,1%.

Theo các nhà nghiên cứu, đây là những con số rất ấn tượng bởi phần lớn pin Li-ion thông thường với các cực bằng Lithium hoạt động ở mật độ dòng điện khoảng dưới 1 mAh/cm2 và thường hỏng sau chưa đầy 300 chu kỳ sạc/xả.

Ngoài việc tăng hiệu suất, chất điện phân mới cũng được cho là có thể mở đường cho một thiết kế mới trong công nghệ pin – được gọi là cell pin không có cực dương. Nói cách khác, bản thân chất điện phân có thể đóng vai trò của một điện cực. Thiết kế thực tế của loại cell này chắc chắn sẽ cần được tinh chỉnh nhưng với một chất điện phân hoạt động với trên 99% hiệu suất thì các nhà nghiên cứu đang đứng trước một cơ hội để tạo ra một loại pin chỉ có thành phần tích lũy dòng điện tích trái dấu mà không cần đến một vật liệu phản ứng phủ trên cực dương. Việc loại bỏ cực dương cũng giúp giảm chi phí, kích thước và cải thiện độ an toàn của pin sạc.

Dĩ nhiên chất điện phân mới của PNNL vẫn cần trải qua nhiều thử nghiệm và hiệu chỉnh trước khi được thương mại hóa. Zhang cùng các cộng sự đang tiếp tục mở rộng nghiên cứu với nhiều phụ gia khác để cải tiến chất điện phân nhằm đạt được hiệu suất 99,9% – điều kiện tiên quyết để sản xuất thương mại và phát hành trên thị trường.

Nguồn: PNNL